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PREFACE 


The  technology  described  in  this  guidebook  is  part  of  a  broad  approach  to  software  productiviQr 
improvement.  This  preface  provides  an  overview  of  that  approach  and  identiries  the  series  of  guide¬ 
books  that  support  it.  These  guidebooks  were  developed  by  the  Software  Productivity  Consortium 
under  contract  to  the  Wginia  Center  of  Excellence  for  Software  Reuse  and  Technology  Ttansfer 
(VCOE).  For  a  complete  listing  of  VCOE  guidebooks  and  products,  call  the  Software  Productivity 
Consortium’s  Technology  Transfer  Clearinghouse  at  (703)  742-7211. 

Each  technology  has  been  packaged  so  it  can  be  used  without  reference  to  the  other  technologies. 
However,  it  is  also  possible  to  combine  these  technologies  into  an  integrated  approach  for  product 
development.  Figure  P-1  shows  how  the  guidebooks  for  these  technologies  relate  to  the  practices  of 
software  development  organizations. 


Drivers  and  Trends  End  System 

Contracts 

Figure  P-1.  Structure  for  Integrated  Application  of  Consortium  Technologies 
These  practices  are  composed  of: 

•  Improvement  Efforts  (IE).  Application  of  technology  to  improve  software  development  efforts. 
These  efforts  require  managed  approaches  to  assessment  of  objectives  and  current  ca¬ 
pabilities,  planning  for  the  improvement,  implementation  of  the  plan,  and  measurement  of 
success. 


xi 


•  The  process  model  is  based  on  the  Evolutionaiy  Spiral  Process  model.  This  change  required 
moving  guidance  from  the  previous  five-step  process  model  to  the  correct  activity  in  the 
ESP-based  model.  Guidance  was  added  for  the  new  management  and  risk  analysis  activities 
present  in  the  ESP  model. 

•  Key  guidance  from  Appendix  A  Methods,  was  folded  into  the  process  guidance  and  the 
methods  appendix  was  removed. 

•  Appendix  B  Sources  of  Software  Engineering  Ibchnology  Information,  was  removed  because 
of  maintenance  issues. 

•  The  guidebook  is  now  positioned  to  be  integrated  with  the  Managing  Process  ImprovemenliA 
Guidebook  for  Implementing  Change  (Software  Productivity  Consortium  1993b).  This  re¬ 
quired  adding  information  about  when  and  how  this  guidebook  should  be  used  in  a  process 
improvement  effort. 

•  Guidance  has  been  modified  based  on  comments  received  from  technology  transfer  courses, 
pilot  projects,  and  consulting. 
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•  Development  Efforts.  Development  of  products  that  meet  the  needs  of  customers  and  markets 
or  products  that  make  the  organization  more  competitive  in  meeting  expected  future  needs. 

-  Organizational  Process  Devdt^mmt  (OPD).  Development  of  standardized 
organizational  process  assets  (e.g.,  process  and  method  descriptions,  pro(^ 
enactment  tools)  tailored  for  a  particular  organization. 

-  Product’Une’Based  Product  and  Process  Devdtytment  (PLD).  Development  of 
integrated  product  and  process  assets  (e.g.,  core  products  and  processes  for  adapting 
them  for  particular  customer  needs)  appropriate  for  a  particular  product  line. 

-  Project  Application  Devdopment  (PAD).  Hie  tailoring  and  application  of  organizational 
assets  for  a  particular  product  development  effort 

Table  P-1  describes  how  existing  products  can  be  integrated  to  address  your  organizational  practice. 

Ikble  P-1.  Consortium  Guidebooks  and  Related  Practices 


Guidebook 

Part  Number 

Relationship  to  Software  Practice 

Consortium  Requirements 
Engineering  Method 
Guidebook 

SPC.92O6O-CMC 

Used  for  defining  and  analyzing  requirements 
in  PAD.  Adaptable  for  use  in  PLD. 

Managing  Process 
Improvement:  A  Guidebook 
for  Implementing  Change 

SPC-93105-CMC 

Supports  IE  by  providing  a  process  and 
supporting  guidance  for  initiating  and 
maintaining  an  organizational  process 
improvement  program. 

Process  Definition  and 
Modeling  Guidebook 

SPC-92041-CMC 

Provides  methods  for  defining  and 
documenting  processes  so  they  can  be 
analyzed,  modified,  and  enacted.  Supports  IE 
and  OPD. 

Process  Engineering  with  the 
Evolutionary  Spiral  Process 
Model 

SPC-93098-CMC 

Used  to  iteratively  plan,  manage,  and  control 
PAD  and  PLD.  Used  to  construct 
organization-specific  processes  in  PLD  and 
tailor  them  in  PAD. 

Reuse  Adoption  Guidebook 

SPC-92051-CMC 

Supports  IE  by  providing  specific  process 
improvement  activities  for  incorporating  reuse 
practices. 

Reuse-Driven  Software 
Processes  Guidebook 

SPC-92019-CMC 

Provides  development  approaches  for  PLD 
(domain  engineering)  and  PAD  (application 
engineering)  of  reusable  software  assets. 

Software  Measurement 
Guidebook 

SPC-91060-CMC 

Supports  IE  by  providing  methods  for 
quantitative  assessment  of  project  status. 

Using  New  Technologies:  A 
Technology  Transfer 
Guidebook 

SPC-92046-CMC 

Supports  IE  by  providing  a  process  that 
addresses  how  to  get  an  organization  to  use 
new  technologies. 

This  guidebook  is  the  second  release  of  the  Consortium’s  Technology  Transfer  Guidebook  The 
following  list  summarizes  the  changes  made  to  the  guidebook  since  the  first  version  in  December  1992: 
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1.  MOTIVATING  TECHNOLOGY  TRANSFER 


For  the  past  ten  years,  the  data  processing  profession  has  been  slowly  learning  that  technology  transfer 
is  one  of  its  biggest  problems— not  tAe  biggest  problem. 


Section  Objectives 

I 

1.  E:q>lain  why  you  should 
be  concerned  about 
technology  transfer 

2.  Explain  the  relationship 
between  technology 
tranter  and  process 
improvement 

3.  Describe  the 
guidebook's  contents 


Ed  Yourdon,  Forward,  AgaOs  of  Change 

Using  New  Technologies  provides  practical  guidance  on  how  to 
successful^  transfer  technology  into  your  organization.  Aimed  at  engi* 
neers  and  managers,  the  guidance  is  distilled  from  a  broad  base  of  experi* 
ence  and  research  and  is  illustrated  by  numerous  examples.  This  guidance 
can  be  used  both  as  part  of  a  process  improvement  effort  and  in  support 
of  individual  technology  transfers. 

Section  1.1  lists  the  objectives  of  this  guidebook.  Section  1.2  motivates  you 
to  be  concerned  about  technology  transfer.  Section  1.3  discusses  the  role 
of  technology  transfer  in  process  improvement.  Finally,  Section  1.4 
describes  the  guidebook’s  organization. 


1.1  OBJECTIVES 


This  guidebook  helps  you,  the  technology  consumer: 

•  Understand  the  importance  of  management  support  and  user  buy-in 
to  the  transfer  and  understand  how  to  acquire  them 

•  Ensure  that  the  technology  and  transfer  strategy  are  consistent  with 
your  organization’s  needs  and  culture 

•  Successfully  plan  and  implement  the  technology  transfer 

This  guidebook  helps  you  address  the  challenges— technical,  economical, 
human,  and  organizational— in  making  your  organization  willing  and  able 
to  transfer  and  use  new  technology. 


1.2  WHY  YOU  NEED  TO  BE  CONCERNED  ABOUT  TECHNOLOGY  TRANSFER 

Rapidly  changing  markets,  tighter  budgets,  increasingly  critical  roles  for 
technology,  and  new  government  and  standards’  requirements  are  issues 
that  engineers  and  managers  contend  with  daily.  These  factors  require  or¬ 
ganizations  to  successfully  select,  adapt,  introduce,  and  use  new 
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technologies.  Because  of  these  factors,  all  organizations  transfer  in  new 
technology  at  one  time  or  another;  many  do  so  frequently.  However,  most 
organizations  follow  an  ad  hoc  technology  transfer  process.  Just  as 
developing  software  through  an  ad  hoc  process  leads  to  spending  more 
money  than  is  needed  on  software  development,  transferring  technology 
through  an  ad  hoc  process  also  leads  to  spending  money  on  technology  that 
is  never  recouped  from  using  that  technology. 

In  all  transfers,  regardless  of  the  technology,  you  can  follow  a  similar 
overall  process  for  technology  transfer.  That  is,  the  general  principles  of 
what  you  do  during  a  technology  transfer  will  differ  little;  how  you  do  it 
may  differ  quite  a  bit.  For  example,  in  selecting  a  computer-aided  software 
engineering  (CASE)  tool  or  in  selecting  a  new  network  protocol,  you  should 
talk  to  potential  users  to  understand  their  needs  and  requirements.  How 
you  get  their  input  may  differ,  but  the  fact  that  you  should  get  their  input 
does  not.  You  can  take  the  same  defined  technology  transfer  process  and 
adapt  it  to  each  situation.  This  guidebook  provides  a  defined  technology 
transfer  process  that  you  can  adapt  and  use  in  all  your  transfer  situations. 


Speed  of  Technology  Change  and  Technology  Transfer 

Technologies  are  changing  at  a  dramatically  faster  rate  than  the  rate  at 
which  organizations  transfer  and  use  them.  This  section  recounts  and 
compares  studies  on  these  rates  of  change  in  the  software  industry. 

•  Speed  of  Technology  Change.  The  rate  at  which  new  software 
engineering-based  products  come  into  industry  is  increasing.  The 
CASE  market  alone  experienced  tremendous  growth  during  the  late 
1980s  and  early  1990s  with  a  forecasted  growth  of  $1  billion  in  1989  to 
over  $5  billion  in  1995  (Software  Productivity  Group  1991).  Competi¬ 
tion  for  the  growing  market  resulted  in  hundreds  of  CASE  vendors, 
with  no  one  vendor  having  more  than  7.8%  of  the  market  in  1990  (Soft¬ 
ware  Productivity  Group  1991).  Another  example  of  fast  technological 
change  is  the  workstation  market.  Sun  Microsystems,  Inc.,  takes  only 
an  average  of  18  months  to  introduce  a  new  product  that  doubles  the 
performance  of  the  previous  product— at  relatively  the  same  price 
(Stalk  and  Hout  '  J90).  Bill  Joy,  one  of  Sun’s  founders,  said  that  Sim’s 
strength  is  in  the  . .  recognition  of  a  central  truth:  technological 
ch&ng'*  in  the  computer  industry  is  continually  accelerating”  (Stalk  and 
Hout  1>90). 

•  Speed  of  Technology  Tranter.  The  classic  mid-1980’s  study  of  the 
maturation  of  14  software  technologies  by  Redwine  and  his  associates 
showed  that,  on  average,  it  took  about  18  years  to  go  from  seminal  pa¬ 
per  or  prototype  to  the  beginning  of  popular,  commercialized  use 
(Redwine  and  Riddle  1985;  Redwine  et  al.  1984).  During  the  same  time 


. ,  technoloffcal 
change  in  the  computer 
industry  is  continually 
accelerating.  ” 

Bill  Joy,  cofounder  of 
Sun  Microsystems,  Inc. 


It  takes  between  4  and  8 
years  for  an  organization 
to  institutionalize  a  new 
technology. 

R.  R.  Willis,  1983 


1-2 


1.  Motivating ‘IbchiiologyThuiifcr 


frame,  reporting  from  a  consumer  point-of-view,  Willis  (1983) 
concluded  that  it  took  6,  plus  or  minus  2,  years  to  transfer  a  complex 
technology  completely  into  an  organization.  Bayer  and  Melone  (1989) 
surveyed  over  75  firms  in  1989  on  their  experiences  in  adopting  5  soft¬ 
ware  engineering  innovations.  They  reported  a  wide  disparity  in  the 
time  it  took  different  firms  to  start  effectively  using  the  same  itmova- 
tion;  for  example,  one  firm  started  using  software  cost  models  22  years 
before  another  firm.  The  shortest  time  differential  of  any  of  the 
technologies  studied— in  this  case,  use  of  Ada— was  still  6  years. 


One  way  to  keep  up  mth 
tecfmolopcal  change  is 
to  reduce  the  time  it 
takes  to  transfer  in  new 
technolopes. 


•  Comparing  the  Speeds.  A  great  dispari^  exists  between  the  average  rate 
at  which  an  organization  transfers  in  a  new  technology  and  the  average 
rate  at  which  technology  changes.  In  fact,  if  a  company  started  to  trans¬ 
fer  a  CASE  tool  now,  that  CASE  tool  would  likely  be  obsolete  by  the 
time  it  was  institutionalized.  Also,  if  a  company  were  to  buy  new  com¬ 
puters  this  year,  they  run  the  real  risk  of  faster,  smaller,  and  cheaper 
computers  being  available  next  year. 


Given  all  of  this,  you  might  find  it  hard  to  justify  the  cost  of  transferring 
in  a  new  technology  when  waiting  a  year  would  bring  a  faster,  better  tech¬ 
nology.  However,  if  you  do  wait,  you  must  assess  the  impact  of  delay  on 
your  competitive  advantage,  market  share,  or  other  business  priorities  and 
on  the  potential  difficulty  of  transferring  in  the  second  generation  of  a  tech¬ 
nology  without  having  assembled  the  experience  from  the  first  generation. 
In  any  case,  one  way  of  keeping  up  with  technology  change  is  to  reduce  the 
time  it  takes  you  to  transfer  technology.  A  goal  of  this  guidebook  is  to  do 
just  that:  to  define  a  process  for  technology  transfer  that  you  can  adopt 
and  improve,  shortening  the  time  it  takes  you  to  use  new  technologies. 


13  TRANSFER’S  CRITICAL  ROLE  IN  PROCESS  IMPROVEMENT 


Improving  your 
organization’s 
development  process 
requires  you  to  be 
successjul  at  technology 
transfer. 


Efforts  toward  improving  an  organization’s  development  process  have 
been  receiving  much  publicity  and  attention.  The  Software  Engineering  In¬ 
stitute  (SEI),  under  contract  to  the  Department  of  Defense  (DoD),  devel¬ 
oped  a  model,  the  Capability  Maturity  Model  (CMM)  (Paulk  et  al.  1991), 
against  which  an  organization  cau  measure  the  maturity  of  its  software  de¬ 
velopment  process  and  against  which  DoD  is  measuring  companies’  abili¬ 
ties  to  bid  on  DoD  contracts.  Similar  efforts  are  under  way  for  the  systems 
engineering  and  government  acquisition  processes. 


The  Evolutionary  Spiral  Process  (ESP)  (Software  Productivity  Consortium 
1993a),  a  process  for  product  development,  strives  to  improve  your  situa¬ 
tion  as  you  progress  through  the  development  life  cycle  by  continuously 
analyzing  and  managing  your  risk.  Further,  process  groups  focused  on  im¬ 
proving  an  organization’s  development  processes,  such  as  a  Software  Engi¬ 
neering  Process  Group  (SEPG),  are  showing  up  in  DoD  contracting 
organizations  around  the  United  States. 
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Improving  your  organization’s  development  processes  involves  the  use  of 
new  technologies.  For  example,  measurement  programs  and  quality  assur* 
ance  programs  must  be  instituted  to  move  up  to  higher  CMM  levels.  'S> 
increase  your  organization’s  chances  of  improving  its  development  pro¬ 
cesses,  an  organization  needs  to  increase  its  chances  of  successfully  using 
new  technologies. 


Relationship  of  Technology  Transfer  to  Process  Improvement 

Process  improvement  and  technology  transfer  have  the  same  high-level 
goal;  to  improve  your  organization’s  practices  changing  the  way  the  staff 
works.  What  differs  is  the  focus.  Process  improvement  focuses  on  the  im¬ 
provement  of  an  entire  process;  technology  transfer  focuses  on  the  im¬ 
provement  of  a  particular  process  area  through  use  of  a  new  technology. 
In  fact,  a  process  improvement  effort  will  invoke  several  technology  trans¬ 
fer  efforts  as  it  finds  areas  in  the  organization  that  need  to  use  a  new 
technology. 

lb  implement  and  support  this  relationship,  this  guidebook  and  the 
Managing  Process  Improvement:  A  Guidebook  for  Implementing  Change 
(Software  Productivity  Consortium  1993b)  are  integrated  and  have  the 
same  organization  and  format.  The  integration  uses  the  following 
guidelines: 

•  Similar  Processes.  Since  the  high-level  goal  of  process  improvement  and 
technology  transfer  is  similar,  the  processes  in  each  guidebook,  includ¬ 
ing  the  activities  and  the  ordering  of  the  activities,  are  similar.  What 
is  different  is  the  focus  and  scope  of  those  activities. 

•  Similar  Giddance.  Each  guidebook  contains  general  guidance  that 
applies  to  both  processes  and  specific  guidance  that  is  tailored  to  each 
process;  this  latter  guidance  is  what  makes  the  guidebook  unique  to 
the  problem  that  it  is  helping  you  solve.  The  guidance  that  is  similar 
to  both  processes  is  repeated  in  both  guidebooks  to  support 
standalone  use. 

•  Similar  Appearance.  The  two  guidebooks  intentionally  have  a  sinular 
organization  and  look-and-feel  so  that  you  can  easily  transition  from 
one  guidebook  to  the  other. 

1.4  ROADMAP  TO  THIS  GUIDEBOOK 

This  section  highlights  initial  guidebook  assumptions;  changes  since  the 
last  version;  guidebook  contents;  and  audience  of  this  guidebook. 

Initial  Assumption:  Where  Does  This  Guidebook  Start? 

This  guidebook  assumes  that  you  or  your  organization  has  identified  an 
opportunity  to  use  a  specific  technology  or  a  need  that  can  be  met  by  the 
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use  of  a  new  technology.  For  example,  your  organizadcm  may  want  to 
improve  current  cmifiguration  management  practices  or  use  the  latest 
object-oriented  design  method. 


Gutoebook  Organization 


This  guidebook  is  organized  as  follows: 

•  Section  1,  Motivating  'Kchnology  Tl*ansfer,  justifies  the  use  of  a 
technology  transfer  process  and  gives  you  a  roadmap  to  the 
guidebook’s  contents. 

•  Section  2,  Understanding  the 'Kchnology'Sransfer  Process,  introduces 
the  technology  transfer  process,  introduces  technology  transfer  con¬ 
cepts,  and  gives  you  the  information  you  need  to  start  and  use  the 
process  guidance. 

•  Sections  3  through  7  contain  guidance  for  the  five  steps  of  the 
technology  transfer  process  as  follows: 

-  Section  3,  Look  at  Your  Situation:  Understand  Context,  helps  you 
understand  your  internal  and  external  environment  regarding  the 
transfer  and  define  objectives  and  strategies  for  how  to  proceed. 

-  Section  4,  Choose  the  Right  Path:  Analyze  Risks  and  Select 
Strategy,  helps  you  understand  the  risks  associated  with  the 
transfer  and  select  the  right  strategy  to  follow. 

-  Section  5,  Focus  the  ’Ransfer:  Plan  Technology  Implementation, 
helps  you  plan  the  next  step  of  the  technology  implementation. 

-  Section  6,  Getting  it  Done:  Implement  Technology,  helps  you 
implement  the  transfer  as  defined  in  the  plan. 

-  Section  7,  Determine  Where  to  Go  Next:  Review  and  Update 
Transfer  Plan,  helps  you  understand  the  results  of  the  transfer  to 
date  and  how  to  proceed  based  on  the  results. 

•  Section  8,  Improving  Your  'Kchnology  Transfer  Process,  provides 
general  guidelines  for  how  to  become  proactive  in  technology  transfer. 

•  The  Appendix,  Checklists  for  Applying  the  Tfechnology  Ttansfer 
Process,  provides  checklists  that  summarize  the  tasks  you  would 
perform  in  a  technology  transfer. 


Audience 


Tb  clarify  what  sections  you  should  read,  Table  1-2  identifies  generic 
audience  types  and  the  sections  of  this  guidebook  that  each  should  read. 
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Keep  in  mind  that  at  any  one  time  you  may  fit  the  descripticm  of  more  than 
one  audience  type;  for  example,  you  may  control  resources  as  well  as  be 
a  user  of  new  technology. 


l^Ie  1-2.  Guidebook  Audience 


Section 

Audience  lype 

■ 

2 

3-7 

(Process) 

8 

■ 

Person  implementing  transfer 

Person  controlling  resources 

Person  advocating  use  of  a 
technology 

Person  using  technologies 

Person  improving  an 
organization’s  transfer 

process 

2.  UNDERSTANDING  THE 
TECHNOLOGY  TRANSFER  PROCESS 


A  competitive  world  has  two  possibilities  for  you.  You  can  lose.  Or,  if  you  want  to  win,  you  can  change. 

Lester  C.  Thurow,  Dean,  MTT  Sloan  School  of  Management 

Sec^n  Objective  This  section  introduces  the  technology  transfer  process  and  concepts 

described  in  this  guidebook  and  then  provides  hints,  suggestions,  and  ad- 

Intr^uce  and  e^lain  the  ^  throughout  the  process.  Read  this  section  before  you 

technolow  transfer  process  *  _  •  ..u 

^  ^  start  using  the  process. 

2.1  A  TECHNOLOGY  TRANSFER  PROCESS 

When  planning  technology  transfer,  it  is  natural  to  envision  implementing 
a  series  of  activities  performed  one  after  another.  The  planner  is  tempted 
to  lay  out  a  scheme  of  such  activities  joined  by  arrows  with  planned  start 
and  finish  dates  for  each.  Unfortunate^,  successful  technology  transfer 
never  follows  such  a  well-structured  plan.  Planners  are  unable  to  accurate¬ 
ly  foresee  all  of  the  (tynamics  that  will  shape  actual  accomplishment  of  pro¬ 
cess  steps.  Experience  has  shown  that  straight  line  (often  called 
“waterfall”)  plans  are  ineffective. 

Technology  transfer  activities  and  their  completion  dates  cannot  be 
accurately  predicted.  However,  a  well-structured  and  implementable  plan 
can  be  developed  by  considering  a  set  of  core  activities,  planned  and  ex¬ 
ecuted  in  an  iterative  manner,  that  successfully  identifies  th?  specific 
transfer  steps  to  be  accomplished  and  projected  dates  for  completion.  Fig¬ 
ure  2-1  presents  the  steps.  Th^r  are: 

•  Step  1:  Understand  Context 

•  Step  2:  Analyze  Risks  and  Select  Strategy 

•  Step  3:  Plan  Technology  Implementation 

•  Step  4:  Implement  Tfechnology 

•  Step  5:  Review  Update  TJansfer  Plan 

The  steps  are  illustrated  as  a  spiral  to  portray  how  you  cycle  through  these 
steps  (clockwise  movement  around  the  diagram  center)  continually  as  you 
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Figure  2-1  Technology  Ihinsfer  Process 

progress  (moving  away  from  the  center  of  the  diagram)  toward  your  goal. 
In  each  cycle,  you  can  accurately  assess  progress,  identify  alternative  next 
steps,  ev^uate  risks,  and  successfully  plan  the  next  increment.  The  plan 
recognizes  that  you  may  need  to  iterate  (do  two  or  more  cycles)  toward  a 
given  goal.  For  example,  a  pilot  use  of  a  technology  may  not  have  achieved 
all  its  objectives,  and  you  may  decide  to  devote  another  cycle  to  achieve 
a  higher  level  of  progress. 

The  remainder  of  this  guidebook  helps  you  structure  your  technology 
transfer  process  using  this  successful  approach  based  on  the  ESP  model 
(Software  Productivity  Consortium  1993a). 


2.2  TECHNOLOGY  TRANSFER  SCENARIO 

You  perform  a  technology  transfer  by  repeating  the  five  steps,  or  one  qrcle, 
until  the  transfer  is  complete  using  the  knowledge  gained  and  lessons 
learned  from  previous  (tycles.  Multiple  cycles  form  a  spiral:  a  spiral  is  one 
or  more  cycles  that,  when  combined,  accomplish  a  specific  objective  such 
as  a  complete  technology  transfer  or  other  major  milestone. 

Figure  2-2  depicts  a  spiral  (starting  from  the  inside  and  growing  out)  that 
highlights  the  main  activities  of  a  typical  technology  transfer  process  using 
the  process  defined  in  this  guidebook.  Dotted  and  dashed  lines  are  used 
to  differentiate  between  the  different  tycles.  This  technology  transfer  pro¬ 
cess  is  based  on  the  scenario  that  one  or  more  staff  members  decide  to 
pursue  use  of  a  new  technology  within  their  organization,  starting  without 
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management  support.  Th^  staff  members  are  the  change  agents.  The  rest 
of  this  section  explains  each  cycle  in  the  spiral. 


Context 
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Figure  2-2  An  Example  of  a  Technology  Transfer  Process 


Cycle  1:  Plan  Transfer 


In  Cycle  1,  the  goal  of  the  change  agents  is  to  develop  a  plan  for  the  transfer 
that  th^  will  use  in  Cycle  2  to  get  management  support  and  funding.  The 
activities  in  Cycle  1  are: 

•  Define  alternative  strategies  based  on  an  understanding  of  how  the 
technology  will  affect  the  organization  (Define  Strategies  and 
Understand  Process  in  Step  1) 
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•  Analyze  risks  and  select  a  strategy  to  follow  and  a  technology  to 
transfer  (Analyze  Transfer  and  Technology  Risks  and  Select  Strategy 
and  Technology  in  Step  2) 

•  Define  a  plan  for  how  to  proceed  (Plan  Transfer  and  Define  Budget 
in  Step  5) 

Steps  3  and  4  are  not  performed  in  Cycle  1  because  those  steps  focus  on 
implementing  the  transfer,  and  the  change  agents  are  cunently  focused  on 
developing  an  overall  transfer  plan. 

At  the  commit  activities  (the  activities  in  boxes  at  the  end  of  each  step)  for 
Steps  1, 2,  and  5  in  Cycle  1,  the  change  agents,  along  with  any  supporting 
champions,  review  and  commit  to  proceed.  At  the  end  of  Cycle  1,  the 
change  agents  have  a  transfer  plan  detailing  their  strategy  and  plan  for  how 
to  proceed. 

Cycle  2:  Build  Sponsorship  and  Foundation 

The  change  agent’s  goal  in  Cycle  2  is  to  get  management  support  for  the 
transfer  based  on  the  transfer  plan  and  develop  the  necessary  foundation 
to  proceed  with  the  transfer.  The  activities  in  Cycle  2  are: 

•  Get  explicit  management  support  and  funding,  confirm  or  establish 
other  roles  for  the  transfer,  and  define  alternative  cycle  strategies 
(Build  Sponsorship  and  Foundation  and  Define  Cycle  Strategies  in 
Step  1) 

•  Analyze  and  resolve  risks  based  on  the  sponsorship  and  foundation 
built  in  the  first  step  (Analyze  and  Resolve  Risks  in  Step  2) 

•  Update  plans  and  budget  and  plan  the  next  cycle  (Update  Transfer 
Plan,  Update  Budget,  and  Plan  Next  Cycle  in  Step  5) 

If,  in  Cycle  2,  management  wants  changes  to  the  transfer  plan  before  they 
agree  to  support  it,  then  the  change  agents  may  perform  one  or  more  cycles 
incorporating  these  changes  and  analyzing  the  risks  of  and  getting  buy-in 
to  the  modified  plan.  The  change  agents  run  a  high  risk  of  failure  if  they 
proceed  without  sponsorship. 

Steps  3  and  4  are  not  performed  in  Cycle  2  because  those  steps  focus  on 
implementing  the  transfer  and  the  change  agents  are  currently  focused  on 
getting  sponsorship  and  a  foundation  in  place  to  support  the  transfer. 

At  the  commit  activities  for  Steps  1,  2,  and  5  in  Cycle  2,  the  supporting 
managers,  the  change  agents,  the  end  users,  and  the  champions  review  and 
commit  to  proceed. 

If  the  change  agents  had  management  support  firom  the  beginning,  then 
they  could  have  combined  the  guidance  for  Cycles  1  and  Z 
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Cycle  N;  Implement  Transfer 

From  the  third  cycle  on,  the  goal  is  to  perform  the  actual  transfer.  By  this 
time,  the  change  agents  have  a  plan  for  the  transfer  that  everyone  supports, 
and  they  have  adequate  management  support  and  funding.  In  Figure  2*2, 
the  third  cycle  is  devoted  to  performing  a  pilot  project  of  the  transfer  on 
a  subset  of  the  organization,  and  the  fourth  cycle  expands  use  of  the  tech¬ 
nology  to  more  of  the  organization.  The  activities  in  these  cycles  are: 

Qcle  N  •  Based  on  the  results  of  the  previous  cycle,  reinforce  the  sponsorship 

and  supporting  foundation,  define  alternative  cycle  strategies,  and 
take  another  look  at  the  process  being  changed  by  the  technology  to 
see  whether  any  adjustments  are  needed  (Reinforce  Sponsorship  and 
Foundation,  Define  Cycle  Strategies,  and  Understand  Process  in 
Step  1) 

•  Analyze  and  resolve  risks  for  the  current  cycle  and  select  a  cycle  strategy 
(Analyze  and  Resolve  Cycle  Risks  and  Select  Cycle  Strategy  in  Step  2) 

•  Develop  a  detailed  implementation  plan  for  the  part  of  the  transfer  to 
be  performed  in  the  current  cycle  (Plan  Cycle  Implementation  in 
Step  3) 

•  Implement  the  transfer  for  the  current  cycle  as  defined  in  the  cycle’s 
implementation  plan  and  monitor  and  manage  the  implementation 
(Train  First  Set  of  Users/Train  Next  Set  of  Users  and  Pilot  Transfer/ 
Transfer  to  Next  Part  of  Organization  in  Step  4) 

•  Review  the  progress  of  the  current  cycle’s  implementation,  update  the 
transfer  plan  accordingly,  and  plan  the  next  cycle  (Review  Progress, 
Update  Transfer  Plan,  Update  Budget,  and  Plan  Next  Cycle  in  Step  5) 

At  each  commit  activity  in  Cycle  N,  the  supporting  managers,  the  change 
agents,  the  end  users,  and  the  champions  commit  and  review  to  proceed. 

23  UNDERSTANDING  TECHNOLOGY  TRANSFER 

Technology  transfer  can  result  in  a  positive  change  for  the  organization. 
People  start  using  technologies  that  work  better  than  what  they  had  been 
using;  productivity  and  morale  increase;  and,  as  people  increase  their  skills 
base,  they  appreciate  the  organization’s  investment  in  them.  New  technolo¬ 
gy  use  also  stimulates  creativity  as  people  see  new  ways  of  working  and 
solving  old  problems.  Though  getting  people  to  change  can  be  difficult, 
once  you  establish  a  culture  of  change  through  successful  technology 
transfers,  people  are  eager  for  newer  and  better  ways  of  working. 

However,  successful  technology  transfer  depends  on  getting  people  to 
change  the  way  they  work.  To  do  this,  you  need  to  understand  and  manage 
the  change  effort  as  it  occurs,  focusing  on  how  the  change  affects  each 
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person  from  their  point  of  view.  This  section  helps  you  understand 
technology  transfer  by  describing  the  players  involved,  specific  transfer  in* 
fluences,  where  you  can  put  responsibility  for  technology  transfer  in  your 
organization,  and  technology  transfer  success  factors. 

Technology  Transfer  Players;  Producers  and  Consumers 

Ihchnology  transfer  Qrpically  involves  many  interactions  among  many 
organizations.  Each  of  these  organizations— whether  a  technology  produc¬ 
er,  a  technology  consumer,  or  other  organization— pursues  goals  and 
forms  relationsUps  that  affect  the  success  of  the  transfer.  Successful  pro¬ 
ducers  provide,  evolve,  and  support  technologies  that  match  consumer 
needs,  and  successful  consumers  are  willing  and  able  to  use  new  technolo¬ 
gies.  However,  being  successful  at  technology  transfer  usually  presents  dif¬ 
ficult  challenges  (that  are  frequently  not  fully  overcome).  For  most  new 
technologies,  central  to  overcoming  these  challenges  is  a  cooperative, 
active  relationship  between  the  producer  and  consumer  that  involves  an 
exchange  of  requirements,  funds,  products,  services,  and  feedback. 

In  general,  technology  producers  try  to  get  consumers  to  use  their  products 
(technology  push)  while  consumers  look  for  a  technology  to  solve  their 
problem  (requirements  pull).  These  two  kinds  of  actions,  or  goals,  are 
depicted  in  Figure  2-3.  For  each  player,  the  goal  may  be  for  either 
short-  or  long-term  purposes. 


Source:  Adapted  from  Fowler  and  Przybylinsid  (1988). 

Figure  2-3.  Technology  Transfer  Producers  and  Consumers 


Technology  Transfer  Influences 

Technology  transfer  is  affected  and  complicated  by  technological,  human, 
and  organizational  influences. 

•  Technological  Ii\f!uences.  The  transfer  of  a  technology  is  influenced  by 
the  technology’s  nature  and  maturity.  The  nature  of  the  technology, 
which  impacts  the  effort  required  for  transfer,  depends  on  the  type  of 
technology  and  its  compatibility  with  the  consumer’s  existing 
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environment.  The  maturity  of  a  technology  is  reflected  not  only  in  the 
current  stage  of  its  life  cycle  (e.g.,  whether  it  is  in  research,  initial  use, 
or  has  been  institutionalized  within  industry),  but  also  in  the  produc¬ 
er’s  ability  to  provide  adequate  training  and  support  and  in  industry’s 
ability  to  provide  related  standards  and  integrated  technologies. 

•  Human  Influences.  People  problems  are  one  of  the  most  important 
areas  in  transfer  and  are  typically  least  understood  by  engineers  and 
managers.  Producer  personnel  become  enamored  with  technology  and 
fail  to  understand  what  is  really  needed  by  the  users.  Consumer  per- 
sotmel  frequently  resist  the  change  to  a  technology  that  they  do  not 
know  or  have  strong  ties  to  another  technology  (e.g.,  prefer  one  type 
of  computer  to  another).  Because  of  these  influences,  there  will  be 
strong  champions  and  strong  opponents  in  any  transfer. 

•  Organizational  Influences.  Producers  and  consumers  affect  technology 
transfer  by  their  organization’s  type,  structure,  culture,  and  politics. 
These  influences  affect  the  organization’s  ability  to  support  the  trans¬ 
fer,  end  users’  willingness  and  ability  to  use  the  new  technology,  and 
management’s  willingness  to  take  risks  and  tty  out  new  technologies. 

Placing  Responsibiutv  for  Technology  Transfer  in  Your  Organization 

You  can  assign  responsibility  for  technology  transfer  in  several  ways:  on 
a  case-by-case  basis  to  an  individual  or  temporary  group  (e.g.,  a  grass¬ 
roots  campaign),  on  a  permanent  basis  to  a  technology  transfer  function, 
or  on  a  permanent  basis  to  an  existing  group.  Ikble  2-1  highlights  the 
advantages  and  disadvantages  of  each  option. 


Tlible  2-1.  Technology  Transfer  Responsibility  Options 


Options 

Advantages 

Disadvantages 

Case-by- 
Case  Basis 

Low  to  no  overhead  costs. 

Process  improvements, 
integration  of  strategy  and 
approaches,  and  use  of 
economies  of  scale  and 
technology  costs  are  all 
done  on  an  ad  hoc  basis. 

Technology 

Tl^nsfer 

Function 

Lower  technology  costs  due  to 
economies  of  scale. 

Ensures  integration  of  technology 
strategies  and  improvement  of 
transfer  process. 

Higher  overhead  costs. 

Assigned  to 
Existing 

Lower  overhead  costs. 

Group’s  existing 
responsibilities  constrain 

Group 

Allows  for  lower  technology  costs 
due  to  economies  of  scale, 
integration  of  technology 
strategies,  and  improvement  of 
transfer  process. 

their  availability  to  focus  on 
transfer  issues. 
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What  Makes  Technology  Transfer  Successful? 


Successful  technology  transfer  depends  on  getting  people  to  change  the 
way  they  work.  Usually,  you  can’t  be  successful  at  getting  people  to  change 
just  by  mandating  it  or  by  handing  them  a  new  technology  and  expecting 
them  to  use  it.  You  have  to  show  them,  in  detail,  how  the  change  will  impact 
their  work  in  the  short-  and  long-term,  ensure  that  they  are  motivated  to 
change,  and  then  support  them  throughout  the  transfer.  Figure  2-4  lists 
factors  that,  if  implemented,  will  improve  your  chances  of  successfully 
transferring  technology. 


2.4  STARTING  AND  PLANNING  A  TECHNOLOGY  TRANSFER 

You  should  apply  the  following  guidance  when  starting  a  technology 
transfer  and  during  subsequent  planning  activities. 

•  Needed  Commitment.  Your  sponsors  need  to  understand  that  if  they 
attempt  a  transfer  and  fail,  they  incur  the  following  costs  (adapted 
from  Implementation  Management  Associates  1992): 

-  Short-Term  Costs.  Direct  costs  include  wasted  resources  and  failure 
to  achieve  a  stated  business  objective.  Indirectly,  staff  morale  suf¬ 
fers  because  th^  may  have  invested  their  own  time  and  energy  in 
a  failed  transfer. 
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-  Long-Tirm  Costs.  If  management  commits  to  something  that  fails, 
then  the  staff  will  potentially  have  less  confidence  in  managemoit’s 
leadership  abiliQr  and  will  increase  their  resistance  to  the  next 
transfer  that  they  are  asked  to  support. 

lb  avoid  these  costs,  your  sponsors  need  to  support  the  transfer 
throughout  the  entire  process.  Th^  cannot  give  the  transfer  lip  service 
only,  expect  it  to  succeed,  and  not  expect  any  repercussions  ^en  it 
fails.  If  there  is  any  doubt  about  whether  you  will  receive  ongoing  sup¬ 
port,  then  you  should  get  new  sponsors  or  delay  the  transfer  until  you 
receive  support.  Otherwise,  the  transfer  may  fhil. 

•  Cost  and  Schedule.  Most  technology  transfers  are  expensive.  If  you  are 
tight  on  resources,  then  you  can  possibly  make  up  for  it  in  the  begin¬ 
ning  by  stretching  out  your  schedule,  but  there  will  come  a  time  when 
management  will  have  to  provide  adequate  resources.  If  you  are  lim¬ 
ited  on  time  and  resomces  (and  cannot  change  the  situation),  the  best 
guidance  is  to  delay  the  transfer  until  your  situation  improves. 

•  TTffiinig.  Organizations  perform  work  and  for  the  most  part  can  only 
perform  work  when  they  have  a  stable  environment.  If  at  all  possible, 
time  the  transfer  to  occur  at  the  beginning  of  an  effort  or  at  a  major 
transition  point  when  people  are  able  to  absorb  technology  changes 
better.  It  is  nearly  impossible  to  get  an  existing  project  to  change, 
especially  when  it  is  in  the  middle  of  schedule  and  resource  cnmches. 

•  Activity  Duration.  Perform  the  transfer  activities  as  rapidly  as  possible 
by  performing  activities  and  tasks  concurrently.  This  might  mean  trad¬ 
ing  elegance  and  perfection  for  speed.  For  example,  a  market  analysis 
completed  in  a  week  that  is  65%  correct  provides  more  value  than  an 
80%  correct  product  done  in  a  month. 

•  Cycle  Duration.  The  length  of  a  cycle  will  depend  on  your  situation. 
However,  you  can  use  the  following  rules  of  thumb  when  planning  a 
cycle: 

-  The  more  people  involved  in  the  current  cycle,  the  shorter  the  cycle 
should  be  because  of  the  higher  probability  that  risks  will  occur. 

-  The  more  comfortable  your  organization  is  with  the  activities 
planned  for  the  cycle  (e.g.,  training),  the  longer  the  cycle  can  be  be¬ 
cause  your  organization  already  knows  how  to  mitigate  most  of  the 
risks. 

One  possibility  is  to  time  the  cycles  to  correlate  with  your  reporting 
cycle;  for  example,  if  management  wants  to  see  a  progress  report  every 
3  months,  then  you  can  time  your  cycles  to  be  approximately  3  months 
in  length. 
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of  impact  on  eadsdng  practices  of  eadi  techndogy  type,  bi  general,  die 
following  are  tn»: 

-  'Dransferring  in  a  tool  alone  will  take  the  least  amount  of  resources 

-  Hransferring  in  a  method  alone  will  take  more  resources 

-  'Kansferring  in  a  tool  and  associated  method  together  will  take 
even  more  resources 

-  Hransferring  in  a  system  or  software  development  life*cycle  process 
will  take  the  most  resources. 

Example  2-1  d^ribes  how  different  transfers  can  be  tailored. 


Joe  Dalton,  System  Manager  for  ^jex  Manufiurturing,  wants  to  implement  three 
new  technolo^  in  the  forthcoming  year.  One  is  a  word  processing  program,  the 
second  a  new  electronic  mail  system  (there  is  currently  no  E-mail  system  in  the 
company);  and  the  third  a  new  method  for  doing  software  testing.  Joe  presents  a 
proposal  to  his  chfof  curating  officer,  Mr.  Harry  Hardnose,  to  provide  16  hours 
of  training  for  all  affected  staff  on  each  technok^  and  a  1/2-time  staff  person  for 
internal  help  for  each  technology. 

Hardnose  is  clearly  not  pleased  with  this  proposal  “You're  going  to  introduce  a  new 
testing  methodology  with  only  16  hours  of  trairting  for  the  staff?,”  he  sneers. 

Joe  tries  to  defend  himself,  “But  we  do  testing  now  and  this  shouldn’t  be  much 
different” 

Hardnose  can  hardly  contain  his  laughter.  “And  we’re  going  to  take  the  entire 
company  off-line  for  2  days  to  learn  how  to  send  recipes  and  memos  faster?,” 
Hardnose  asks. 

Joe  replies,  “Weil,  I  didn’t  want  anyone  to  feel  left  out”  Hardnose  tells  Joe  he’d 
better  have  a  more  appropriate  implementation  plan  on  his  desk  in  the  morning. 
Upon  reflection,  Joe  realizes  that  the  new  version  word  processor  is  a  relatively 
minor  implementation  activity  because  there  is  already  a  previous  version  in  place. 
Therefore,  he  plans  a  l-hour  training  program  and  distribution  of  the  latest 
documentation. 

Implementation  of  the  new  E-mail  system  is  somewhat  larger,  though  still 
compatible  with  the  existing  cultural  practices  and  organization  of  the  company. 
This  will  require  a  2-hour  training  program,  supplemented  by  implementation 
assistance  and  an  ongoing  program  for  several  months  to  work  out  bugs  in 
operatioru 

The  implementation  of  the  new  testing  method  can  potentially  cause  major 
disruptions.  Joe  expects  that  he  will  need  several  days  of  off-site  training  for  the 
technical  staff  and  a  consultant  to  redesign  jobs  and  job  descriptions  of  the 
technical  and  support  staff.  It  is  likely  that  some  adjustments  will  ne^  to  be  made 
in  other  software  engineering  methods  and  tools  in  use.  In  addition,  project 
managers  will  need  4  to  6  hours  of  training.  The  whole  implementation  is  expected 
to  take  several  months. 

Joe  presents  his  new  proposal  to  Mr.  Hardnose  who  accepts  it,  but  without  a  smile 
or  other  sign  of  pleasure.  Some  people  just  have  to  live  up  to  their  name! 


Example  2-1.  A  Case  of  Tailoring  Technology  Transfer  Resources 
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23  USING  THE  TECHNOLOGY  TRANSFER  PROCESS 

This  secdon  e3q>lains  how  the  te(hnak)gy  transfer  process  is  described  in 
SecticHis  3  through  7  and  provides  guiddines  on  how  to  use  the  process. 


Who  Should  Perform  the  Activities? 


Since  staff  at  any  level  in  an  organization  can  play  a  role  in  technology 
transfer,  this  guidebook  defines  generic  roles,  with  corresponding  icons, 
for  the  activities.  'R)  use  these  role  definitions,  identify  your  role(s)  and  fol¬ 
low  the  guidance  v^en  the  conesponding  icon  appears  in  the  margin.  Re¬ 
fer  to  Managing  Process  Improvement:  A  Guidebook  for  Implementing 
Change  (Software  Productivify  Consortium  1993b)  for  clarification  on  Pro¬ 
cess  Groups,  Steering  Committees,  and  Process  Action  Ibams. 

^  •  Sponsor.  This  penon  possesses  sufficient  authorify  or  influence  to 

either  initiate  resource  commitment  (authorizing  sponsor)  or  continu¬ 
ally  reinforce  the  transfer  at  the  local  level  (reinforcing  sponsor).  The 
sponsor  is  usually  at  a  senior  management  level.  If  the  transfer  is  part 
of  a  process  improvement  effort,  then  this  role  is  usually  filled  by  a  Pro¬ 
cess  Group  for  technical  issues  and  by  a  Steering  Committee  for 
budget  and  business-related  issues. 


Change  Agent  This  person  or  team,  empowered  by  the  sponsor, 
performs  the  technology  transfer  activities.  The  change  agent  should 
have  some  technical  ocperience,  be  respected  for  personal  or  technical 
leadership,  and  have  insight  into  the  technology  and  business  strategy 
of  the  organization.  If  the  transfer  is  part  of  a  process  improvement 
effort,  then  this  role  is  usually  filled  by  Process  Action  Tbams. 


Champion.  This  person  advocates  and  publicly  supports  tise  of  the 
new  technology  in  the  organization,  though  lacks  power  to  provide  re¬ 
sources  to  support  it.  A  champion  can  be  present  at  any  level  of  an  or¬ 
ganization;  successful  ones  are  usually  respected  for  personal  or 
technical  leadership  by  the  users.  If  the  transfer  is  part  of  a  process 
improvement  effort,  this  role  may  include  the  Process  Group. 


•  End  User.  This  person  or  group  uses  the  new  technology.  The  end  user 
can  be  present  at  all  levels  of  an  organization. 

An  individual’s  role  may  evolve  and  overlap  during  the  transfer.  For 
example,  a  middle  manager  may  initially  be  the  change  agent  and  then  be¬ 
come  a  reinforcing  sponsor  as  additional  staff  are  brought  in  to  fill  the 
change  agent  role. 


In  addition,  the  guidebook  refers  to  the  role  stakeholders.  Stakeholders 
are  people  who  are  involved  with  and  affected  by  the  change.  Stakeholders 
include  the  sponsors,  champions,  end  users,  and  change  agents. 


2-n 


*■  wiwrx«rirTT^  -Tg^  — .  — **_T  "rn  >  »— dt» 


Key  Assumption:  Placing  You  in  the  Process 

There  are  countless  ways  that  you  can  perform  a  transfer  using  this  process. 
Your  rote,  the  tedindogy  you  want  to  transfer,  and  your  oiganizatioa's 
environment  and  culture  all  affect  your  focus  and  scope  bx  the  activities. 
Because  of  the  wide  range  of  possibilities,  the  guidance  in  the  process,  based 
on  the  scenario  outlined  in  Section  22,  uses  the  following  strata  £:»  each 
cycle: 

•  Qfcle  1.  Your  objective  in  Cycle  1  is  to  develop  a  transfer  plan  that  you 
can  use  to  sell  all  stallholders  on  the  transfer. 

•  Ocfe  2.  Your  objective  in  Cycle  2  is  to  get  the  necessary  managers  to 
sponsor  the  transfer  and  to  get  a  foundation  in  place  to  support  the 
transfer. 

•  Cycle  N.  For  the  remaining  cycles,  your  objective  is  to  transfer  the 
technology. 

Following  this  cyclic  strategy  approach  gives  you  a  baseline  against  which 
to  understand  the  process  guidance.  If  your  situation  is  different  from  the 
baseline,  then  you  can  tailor  the  guidance  appropriate^.  For  each  set  of 
guidance,  the  corresponding  cycle  number  is  indicated  in  the  lefthand 
column. 

The  only  situation  you  may  have  that  will  greatly  deviate  from  this  cyclic 
strategy  approach  is  having  the  necessary  management  support  from  the 
begimung.  In  this  case,  you  can  integrate  the  strategies  and  the  guidance 
for  Cycles  1  and  2.  In  the  first  cycle,  then,  you  will  develop  a  plan  and  get 
support  from  other  stakeholders  at  the  same  time. 

Though  you  will  be  performing  the  process  a  cycle  at  a  time,  the  process 
is  organized  by  activity  and  task.  This  was  done  to  group  related  guidance 
together  and  to  support  tailoring.  However,  the  Appendix  provides  a  sum¬ 
mary  of  the  guidance  ordered  by  cycle.  The  summary  is  in  checklist  format, 
allowing  you  to  check  off  the  tasks  as  you  perform  them. 


Things  to  Know  Before  Using  the  Process 

Understand  the  following  before  you  use  this  guidebook: 

•  The  process  guidance  focuses  on  the  group  or  individual  performing 
the  transfer  activities  (the  change  agents).  Other  roles  in  the  process 
are  included  when  th^  are  involved  in  the  task. 
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•  You  can  peiform  each  activity  using  various  organizarional  structures 
and  styles  including  formal  team  meetings,  informal  group  meetings, 
or  work  by  individuals.  How  you  perform  each  activity  depends  (m 
your  own  style  and  your  organization’s  culture. 

•  You  need  to  generate  an  electronic  or  paper  trail  on  your  analyses, 
decisions,  rationales,  and  implementation  efforts.  Many  activities  do 
not  prescribe  a  specific  documentation  type  (e.g.,  a  formal  plan)— the 
type  of  document  you  oreate  is  up  to  you  and  your  management. 

•  Use  existing  data  and  knowledge  wherever  possible.  In  technology 
areas  that  change  rapidly,  be  careful  of  data  over  2  to  3  years  old. 

•  You  may  not  perform  each  activity  in  each  cycle.  For  mmple,  in  the 
first  two  cycles  where  you  are  focused  on  getting  sponsorship  and  real* 
istic  plans  in  place,  you  will  not  perform  the  Implement  activity. 

•  The  list  of  stakeholders  at  each  commit  activity  may  change.  This 
affects  the  amount  of  time  and  resources  needed  to  get  commitment 


How  Are  the  Activities  Formatted? 

Figure  2*5  presents  the  format  of  activity  descriptions.  Each  description 
contains  a  context  diapam  in  the  upper  lefthand  comer  that  serves  as  a 
pointer  to  the  process  diapam  (see  Figure  2-1).  For  each  activity,  the 
corresponding  step  in  the  process  diapam  is  shaded. 

Activities  in  Sections  3  through  7  may  contain  case  studies,  in  the  form  of 
examples,  that  illustrate  the  guidance  in  the  activity.  They  are  based  on  real 
situations:  however,  specific  names  have  been  changed  to  protect  proprietary 
information. 


‘ttamfer  nrooHi 


Name  of  Acthri^ 


A  statement  describing  the  step  containing  this  activity. 


Overview 

{provides  an  overview  of  the  activity. 

Start  Criteria 

Provides  criteria  and  inputs  that  must  be  met  before  the 
activity  can  start 

Ihsks 

Provides  a  detailed  description  of  the  tasks  that  should 
be  performed  in  this  activity. 

Who  should  perform  each  tadc  is  indicated  by  a  role 
icon  placed  next  to  the  first  line  of  each  task.  There  is 
an  icon>to-role  mapping  at  the  bottom  of  each  page. 

CytUN 

The  ^cle  in  «4iich  you  would  foDow  this  guidance  is 
indicated  in  the  left  margin  as  needed. 

Stop  Criteria 

Provides  criteria  and  outputs  that  must  be  met  before  the 
activity  can  finish. 

^SpoMor  ^  OuHTiM  Q  EndUier 

Figure  2-5.  Activity  Format 


3.  LOOK  AT  YOUR  SITUATION: 
UNDERSTAND  CONTEXT 


Excellent  firms  don’t  believe  in  excellence— onfy  in  constant  improvement  and  constant  change. 

Ibm  Peters 


Section  Objectives 

1.  Provide  ffudance  for 
understanding  how  your 
envirorment  will  impact 
thetrmrfer 

2.  Provide  guidance  for 
defining  an  (grpropriate 
transfer  strategy 


For  any  technology  transfer  to  succeed  you  need  to  build  sponsorship  and 
a  support  structure,  identify  a  strategy  that  all  stakeholders  buy  in  to,  and 
understand  the  current  process  to  be  changed.  Figure  3*1  shows  the  four 
activities  described  in  this  section: 


figure  3>L  Understand  Context  Activities 

You  will  not  perform  the  activities  within  the  circle  linearly;  rather  they 
will  share  and  depend  on  information  from  each  other.  You  will  not  per¬ 
form  the  Context  Review  activity  until  after  you  have  completed  the  other 
activities. 
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3.1  BUILD/REINFORCE  SPONSORSHIP  AND  FOUNDATION 


Overview 


Start  Criteria 


Tasks 


This  activity  begins  in  Step  1,  Understand  Context. 


Your  objective  in  this  activity  is  twofold:  ensure  that  you  have  a  foundation 
in  place  and  ready  for  the  transfer  and  ensure  that  you  have  sponsorship 
for  the  transfer. 

A  foundation  comprises  champions,  change  agents,  and  end  users  ready 
to  use  the  new  technology.  Champions  are  needed  to  advocate  the  transfer 
publicly  and  keep  people  supportive  by  constantly  reinforcing  the  benefits 
of  the  technology.  Change  agents  are  needed  to  perform  the  day-to-day 
tasks  of  support,  implementation,  planning,  managing,  and  review.  The 
end  users  need  to  be  ready  for  the  transfer  and  be  adequately  trained  and 
supported. 

Sponsorship  is  a  critical  element  in  any  effort  that  requires  all  or  part  of 
the  organization  to  change  and  needs  to  be  obtained  as  early  in  the  transfer 
as  possible. 


You  should  use  information  and/or  working  knowledge  on  the  following 

items  as  inputs  to  this  activity: 

•  Any  related,  supporting  documents,  including  a  process  improvement 
action  plan  and  any  orgam'zational  strategic  plans 

•  If  a  continuing  transfer,  the  transfer  planning  documents  created  and 
updated  in  previous  cycles,  including  the  transfer  plan,  risk 
management  plan,  implementation  plan,  and  influence  strategy 

•  Any  historical  transfer  information 


You  will  identify  the  change  agents  and  the  champions  for  the  transfer; 
imderstand  who  the  end  users  will  be  for  the  transfer  and/or  cycle  and  their 
readiness  to  change;  identify  sponsors  and  get  their  support  for  the 
transfer;  and  prepare/update  and  implement  an  influence  strategy. 
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3.  Look  at  Your  Situation:  Understand  Context 


1.  Build/Reinfbrce  lyansfer  Support  Staff  (change  i^ents  and  dianipions). 

lb  start  a  new  transfer  or  to  continue  an  in-process  transfer,  you  need  to  make 
sure  that  you  have  the  support  of  change  agmts  and  chainpi(»is. 


Cycle  I  In  Clyde  1,  you  will  plan  the  support  staff  you  need  in  the  transfer  plan. 
Guidance  on  planning  for  change  agents  and  champitxis  follows: 


•  Change  AgeiUs.  An  effective  change  agent  will  have  project  managemrat 
experience,  including  excellent  organizational,  human  rdations,  aiul  com¬ 
munication  skills.  Hie  change  agent  should  be  arable  of  standing  up 
the  transfer  in  the  face  of  adversity  and  have  enou^  experioice  to  urider- 
stand  the  informal  and  formal  workings  of  the  organizatitHi.  For  example, 
the  change  agent  should  have  a  persraial  network  to  feverage  in  tlK  trans¬ 
fer  and  understand  how  the  different  groups  within  the  organizatitm 
interact 


The  number  of  change  agents  you  need  depends  on  the  level  of  impact 
the  technology  will  have  and  the  number  of  end  users.  You  need  clumge 
agents  to  perform  the  following  functions: 

-  Plan  the  transfer  and  the  implementation 

-  Sell  the  transfer  and  implementation  to  all  staff  and  management 
involved  or  impacted  by  the  transfer  (the  stakeholders) 

-  Train  the  end  users  in  the  new  technology 

-  Integrate  the  new  technology  into  the  organization’s  cultural  and 
technical  enviromnent 

-  Provide  technical  support  to  the  end  users 

-  Manage  and  collect  data  on  the  implementation 

-  Review  the  progress  against  the  plan 

•  Champions.  Champions  are  needed  to  advocate  the  transfer  publicly 
and  keep  people  supportive  by  constantly  reinforcing  the  benefits  of 
the  technology.  When  identifying  champions,  qualify  is  more  impor¬ 
tant  than  quantify  (though  quantify  does  not  hurt),  lb  find  champions, 
you  should  ask  management  and  staff  in  the  organization,  especially 
the  affected  parts  of  the  organization,  to  identify  staff  who  are: 

-  Weil  respected  for  personal  and  technical  leadership 

-  Ibchnical  experts  in  the  particular  technology  area 

-  Risk  takers  when  it  comes  to  trying  new  technology 


^  Sponsor 


Change 

Agent 


\T^  Champion 


A  IBnd  User 


3.  Look  at  Your  Situation:  Understand  Context 

Cyck  2  You  need  to  get  the  change  agents  and  champions  identified  in  the  transfer 

plan  to  buy  in  to  the  technology  and  the  transfer.  You  need  a  support  team 
that  works  well  together.  Good  teamwork  stems  from  each  change  agent 
and  champion  communicating  equally,  participating  equally,  and  feeling 
they  all  provide  equal  value  to  the  team. 

You  should  use  your  influence  strategy  (see  Iksk  4  in  this  activity)  to  sell 
the  identified  change  agents  and  champions  on  the  transfer  and  obtain 
their  buy-in  to  support  your  efforts. 

Cycle  N  For  subsequent  cycles,  you  need  to  reinforce  continued  support  from  all 
identified  change  agents  and  champions. 


2.  Identify  End  Users  and  Assess/Reinfwce  Their  Readiness  to  Giange. 
You  need  to  identify  alternatives  for  which  organization  unit(s)  will  use  the 
new  technology  and  then  assess  whether  they  are  ready  for  the  change. 

Alternatives  for  which  end-user  group  to  choose  will  be  heavily  impacted 
by  your  sponsorship  status.  Those  target  units  with  managers  that  strongly 
support  the  transfer  should  be  alternatives  for  the  transfer  early  in  the  pro¬ 
cess;  those  with  managers  who  are  wavering  or  opposed  to  the  transfer 
should  be  planned  for  later,  after  some  success  has  been  achieved.  Because 
of  this  relationship,  you  will  perform  this  task  in  parallel  with  Ihsk  3, 
Build/Reinforce  Sponsorship. 

Cycle  1  Identify  end  users  that  are  open  to  trying  new  technologies;  have  a  need 
for  the  technology;  are  not  in  the  middle  of  a  busy  period;  and  are  at  the 
beginning  of  a  project  or  at  a  major  milestone,  giving  them  more  freedom 
to  change. 

Get  an  initial  understanding  of  whether  the  end  users  are  ready  for  change 
by  talking  with  managers  and  staff  in  the  target  unit  to  get  their  initial  reac¬ 
tion  to  the  transfer.  You  want  to  describe  the  area  that  you  intend  to  im¬ 
prove  with  the  new  technology,  their  expected  role  in  the  transfer,  how  they 
will  be  impacted,  the  expected  benefits  of  the  transfer,  and  the  expected 
transfer  process.  Clarify  that  all  of  this  information  is  preliminary.  In  addi¬ 
tion,  get  their  input  on  technologies  they  would  recommend  and  strategies 
for  how  to  proceed.  This  should  not  be  a  full-scale  assessment  of  their 
readiness;  rather,  the  purpose  of  this  is  to  initially  understand  whether  the 
end-users  are  ready  for  the  transfer  and  to  start  getting  buy-in  to  the 
transfer. 

Qcfe  2  In  Cycle  1,  you  need  to  get  buy-in  from  the  end  users  as  well  as  assess  their 
readiness  for  change.  To  get  buy-in,  you  can  use  the  influence  strategy 
developed  in  Thsk  4  of  this  activity. 
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3.  Look  at  Your  Silualion:  Undenland  Context 


To  assess  the  end  users’  readiness  for  change,  you  must  understand  the 
atmosphere  of  the  end  users’  organization,  indicated  by  both  the  organi¬ 
zation’s  history  of  change  and  the  stress  of  individuals  within  the 
organization  (Implementation  Management  Associates  1992).  You  will: 

•  Examine  prior  technology  change  efforts  to  help  you  understand 
end-user  attitudes  about  change.  Successful  change  experiences  will 
increase  receptiveness  to  the  transfer,  and  you  can  proceed  without 
worrying  about  this  issue;  in  fact,  you  can  possibly  speed  up  the  trans¬ 
fer  schedule  because  you  may  have  to  spend  less  time  gaining  buy-in. 
Negative  change  experiences  can  greatly  decrease  your  chances  of  suc¬ 
cess.  Therefore,  you  should  plan  on  spending  at  least  one  cycle  describ¬ 
ing  the  transfer  and  the  resulting  benefits  to  the  end  users,  focusing 
on  the  expected  immediate  and  long-term  impact. 

•  Understand  the  make-up  of  the  organizational  unit  and  how  that  might 
affect  the  transfer.  Are  there  political  problems  that  might  affect  the 
transfer?  For  example,  does  the  manager  of  the  technical  support 
group  disagree  with  the  transfer?  If  so,  then  that  manager  may  not  be 
willing  to  allocate  the  necessary  resources  to  help  integration  and  tech¬ 
nical  support  for  the  end  users  and  you  need  to  spend  time  selling  the 
transfer.  Political  problems  that  might  affect  the  transfer  should  be 
captured  either  in  the  transfer  constraints  or  categorized  as  a  risk  in 
the  Analyze  and  Resolve  Risks  activity. 

•  Understand  the  level  of  stress  in  the  organization  due  to  other,  parallel 
change  efforts.  Staff  can  only  absorb  so  much  change  and  stay  produc¬ 
tive;  too  much  change  will  cause  them  to  reject  all  change.  If  there  are 
other  changes  going  on  at  the  same  time,  you  should  delay  the  transfer 
until  the  other  changes  have  settled  down.  If  you  cannot  delay  the 
transfer,  then  you  should  include  this  issue  as  a  high  risk  item  in  the 
Analyze  and  Resolve  Risks  activity  and  make  management  aware  that 
too  much  change  is  occurring  at  the  same  time. 

•  Look  at  the  expectations  of  the  target  unit  that  will  use  the  new 
technology.  Do  they  perceive  a  need  for  the  change  or  is  the  change 
being  forced  on  them?  If  the  end  users  do  not  perceive  a  need  for  the 
change,  then  you  should  devote  at  least  one  cycle  describing  the 
change,  the  benefits,  and  the  immediate  and  long-term  impact  on  the 
end  users. 

•  Determine  whether  the  end  users  have  the  required  resources  to  learn 
and  use  the  technology.  If  they  do  not,  then  you  need  to  solicit  the  end 
users’  managers,  your  managers,  and  the  sponsors  for  the  transfer  to 
get  the  required  resources.  You  run  a  high  risk  of  failure  if  the  end  users 
do  not  have  the  resources  to  learn  and  use  the  new  technology— you 
will  not  get  them  to  perform  these  tasks  on  their  own  time. 
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3.  Look  at  Your  Situation:  Understand  Context 

•  Assess  whether  the  end  users  have  the  required  skills  to  benefit  fr(xn 
available  training.  If  not,  then  you  will  need  to  spend  additional  time 
training  or  you  will  need  to  bring  in  people  from  the  outside  to  fill  in 
the  skill  gaps. 

A  negative  response  to  any  one  item  in  the  bulleted  list  is  enough  to  cause 
the  transfer  to  fail.  It  is  important  to  identify  high  risk  areas  now  before 
a  lot  of  effort  is  expended  on  the  transfer.  However,  you  have  to  determine 
whether  to  proceed  based  on  your  own  situation.  If  you  have  no  choice  but 
to  proceed,  capture  these  items  as  risks  in  the  Analyze  and  Resolve  Risks 
activity  and  call  management  attention  to  them  that  way.  Conversely,  if  you 
decide  that  the  end  users  are  not  ready  for  the  change  and  you  have  control 
over  the  transfer,  you  should  delay  the  transfer  until  th^  are  ready,  find 
another  set  of  end  users,  or  discontinue  the  transfer. 

As  you  assess  the  end  users  for  their  readiness  to  change,  use  the 
opportunity  to  inform  them  about  the  impending  transfer  and  get  their 
feedback  and  comments.  This  will  start  getting  their  buy-in  to  the  transfer. 


Cycle  N  In  subsequent  cycles,  you  will  need  to  determine  whether  additional  or 
different  parts  of  the  organization  will  use  the  technology  in  this  cycle. 
Whether  or  not  the  end  users  have  changed  or  expanded,  you  need  to  reas¬ 
sess  their  readiness  for  change  because  their  environment  or  makeup  may 
have  changed.  For  example,  other  change  efforts  may  have  been  invoked 
since  the  last  cycle,  or  the  stafGng  may  have  changed. 


$ 


3.  Build/Reinforce  Sponsorship»  You  need  to  identify  the  sponsors  for  the 
transfer.  Authorizing  sponsors  initiate  resource  commitment  for  technolo¬ 
gy  transfer;  reinforcing  sponsors  reinforce  transfer  efforts  within  their  own 
organizational  area.  Sponsors  provide  funding  and  resources  for  the  trans¬ 
fer  and  publicly  support  the  transfer  to  the  rest  of  the  organization.  Change 
agents  and  champions  cannot  substitute  for  the  sponsor.  You  need  to  have 
a  sponsor  in  each  of  the  areas  of  the  organization  affected  by  the  transfer. 
The  following  list  contains  guidance  on  sponsorship  that  applies  to  the  en¬ 
tire  transfer: 


•  Sponsors  are  most  effective  if  they  have  excellent  management  and 
leadership  skills  to  address  both  the  technical  and  human  aspects  of 
change  and  to  articulate  the  organization’s  vision  and  how  this  transfer 
supports  that  vision. 

•  If  the  transfer  is  part  of  a  process  improvement  effort,  then  the 
authorizing  sponsor  is  likely  the  Process  Group  or  the  Steering 
Committee. 


$ 
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3.  Look  at  Your  Situation:  Undetstand  Context 


•  Sponsors  need  to  continually  sanction  the  transfer  publicly  and 
demonstrate  this  commitment  to  everyone  in  their  organization. 

•  Sponsors  are  most  effective  when  they  can  understand  the  different 
perspectives  all  levels  in  the  organization  will  have  on  the  transfer.  For 
example,  the  realities  of  the  transfer  in  day-to-day  life  will  be  drastical¬ 
ly  different  between  the  engineer  and  senior  manager;  sponsors  need 
to  understand  this  and  be  able  to  alleviate  the  concerns  of  all 
perspectives. 

If  there  is  any  doubt  about  whether  sponsorship  can  be  sustained 
throughout  the  transfer,  then  you  run  a  high  risk  of  implementation  failure, 
which  incurs  short-term  costs  (e.g.,  wasted  resources)  and  long-term  costs 
(e.g.,  reduced  confidence  in  leadership  and  staff’s  lack  of  desire  to  support 
future  changes).  Your  options  at  this  time  are  to  educate  your  sponsors  to 
get  strong  support,  get  new  sponsors,  stop  the  transfer,  or  fail. 

The  approach  you  take  to  getting  sponsorship  will  depend  on  how  your 
organization  makes  decisions  and  on  the  technology’s  characteristics: 

•  Your  organization  may  make  decisions  in  many  different  ways: 

-  A  single,  senior  manager  always  uses  the  hammer  approach  to  get 
others  to  comply.  In  this  first  scenario,  you  need  to  target  the  single, 
senior  manager  as  your  authorizing  sponsor. 

-  Managers  make  their  own  decision  in  a  vacuum.  In  this  scenario, 
you  need  to  obtain  sponsorship  commitment  from  all 
involved  managers  individually. 

-  There  is  cooperative  involvement  in  the  decision  to  support  or  not 
support  the  transfer.  In  this  scenario,  you  can  get  input  from  all 
managers  on  the  best  way  to  sponsor  and  proceed  with  the  transfer 
(e.g.,  which  area  will  pilot  the  technology),  ensuring  cooperative 
buy-in  to  the  transfer. 

•  The  technology’s  characteristics  may  make  one  decision-making 
approach  more  appropriate  than  another.  For  example,  a  simple  tech¬ 
nology  with  minimal  impact  may  be  decided  upon  by  a  single  manager 
and  transferred  through  mandate;  however,  in  practice,  few  technolo¬ 
gies  are  this  simple  and  an  authoritarian  approach  often  backfires.  In 
contrast,  a  technology  that  involves  extensive  changes  should  be  de¬ 
cided  on  in  a  much  more  participative,  extensive  manner  and  you 
should  seek  sponsors  from  all  involved  areas. 

In  the  first  qrcle,  you  need  to  identify  an  authorizing  sponsor  for  the  transfer. 
The  authorizing  sponsor  can  usually  be  identified  by  looking  at  the  original 
impetus  for  the  transfer  (see  Tksk  3  in  the  DefineAJpdate  Tlransfer  Strategies 
activity),  as  follows: 


3.  Look  at  Your  Situation:  Understand  Contest 

•  If  the  transfer  is  a  management  request,  then  the  authorizing  sptmsor 
will  either  be  the  requesting  manager  or  another  manager  designated 
by  the  requesting  manager. 


•  If  the  transfer  is  a  staff,  or  grass-roots,  request,  then  you  need  to  start 
identifying  potential  authorizing  sponsors.  Ihe  best  place  to  start  is  the 
management  of  tltt  staff  members  requesting  the  transfer,  your  manag¬ 
ers,  or  the  managers  of  internal  technical  groups  (e.g.,  an  internal  researdi 
and  development  group). 

After  identifying  an  authorizing  sponsor,  you  need  to  identify  reinforcing 
sponsors.  Reinforcing  sponsors  should  include  the  managers  of  all  of 
groups  affected  by  the  transfer.  In  addition,  in  case  of  reorganizations  or 
shifts  in  responsibilify,  you  should  try  to  get  as  many  managers  to  support 
the  transfer  as  possible.  It  is  important  to  get  managers  of  all  end  users, 
champions,  and  change  agents  to  support  the  transfer. 

If  you  have  management  sponsorship  at  the  beginning  of  the  transfer,  then 
you  can  combine  the  guidance  for  this  cycle  with  the  next. 

Cycle  2  In  the  second  cycle,  you  need  to  get  the  sponsors  you  identified  in  the  first 
cycle  to  support  the  transfer  based  on  your  transfer  plan.  This  means  get¬ 
ting  all  yeses  and  no  noes— even  just  one  of  the  identified  sponsors  can 
throw  a  monkey  wrench  into  the  transfer  if  they  do  not  support  your  efforts. 
You  can  use  the  influence  strategy  described  in  Tksk  4  of  this  activity  to 
help  get  their  sponsorship. 

Cycle  N  For  subsequent  cycles,  you  need  to  reinforce  continued  sponsorship  from 
all  identified  sponsors. 


4.  Prepare/Update  and  Implement  Influence  Strategy.  There  are  winners 
and  losers  in  any  transfer.  This  fact  makes  transfers  difficult  and  emotion¬ 
al  and  necessitates  preparing  a  deliberate  influence  strategy.  An  influence 
strategy  is  a  formal  or  informal,  written  or  unwritten  strategy  for  gaining 
buy-in  from  appropriate  management  and  staff  on  the  technology  and  its 
use  within  the  organization.  The  influence  strategy  prepared  in  this  activity 
will  be  used  throughout  the  technology  transfer  process  each  time  you  need 
to  get  commitment  and  buy-in  to  the  transfer  firom  any  stakeholder. 

Technology  transfer  involves  a  series  of  decisions,  starting  with  the  change 
agents  or  authorizing  sponsors  as  they  decide  to  begin  the  transfer  and 
continuing  to  each  stakeholder  as  they  decide  to  support  or  not  support 
their  role  in  the  transfer.  Deciding  not  to  transfer  is  a  decision  that  can 
be  made  by  one  person;  if  that  person  controls  a  key  resource,  then  your 
transfer  is  put  at  a  high  risk.  You  need  to  realize  that  deciding  to  transfer 
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3.  Look  at  Youf  Siiualion:  Understand  Conteit 


involves  getting  many  “yeses”  and  no  “noes.”  If  you  do  get  a  “no,"  talk  to 
the  person  to  understand  their  reasons  for  deciding  against  the  transfer 
and  diffuse  their  concerns.  Another  possible,  yet  le^  desirable,  option  is 
to  continue  with  the  transfer  (though  this  may  be  impossible  if  the  person 
is  crucial  to  its  success).  In  any  case,  you  need  to  keep  all  of  these  factors 
in  mind  as  you  develop  your  influence  strategies. 

If  the  transfer  is  the  direct  result  of  an  organizational  process  improvement 
effort,  then  you  will  likely  be  coming  into  the  transfer  with  adequate  man¬ 
agement  support.  However,  support  will  be  for  a  process  improvement  ef¬ 
fort  and  not  necessarily  for  the  use  of  a  specific  technology  on  a  specific 
project.  Therefore,  you  need  to  develop  an  influence  strategy  that  focuses 
more  on  the  benefits  of  the  technology  than  on  the  need  for  the  transfer 
itself  and  focuses  more  on  the  end  users  than  on  management 

In  Cycle  1,  you  will  plan  who  should  be  your  end  users,  sponsors,  change 
agents,  and  champions  (see  the  first  three  tasks  in  this  activity).  You  should 
develop  an  influence  strategy  based  on  those  plans,  but  realize  that  as  your 
plans  change,  your  influence  strategy  might  also  need  to  change,  lb 
prepare  an  influence  strategy,  you  will: 

•  Identify  stakeholders.  Identify  all  of  the  stakeholders.  This  information 
will  come  primarily  from  the  results  of  performing  the  first  three  tasks 
in  this  activity;  however,  there  are  real  and  potential  stakeholders  that 
are  not  directly  involved  in  the  transfer.  For  example,  if  the  technology 
directly  affects  a  customer  or  supplier,  then  you  should  include  them 
as  a  stakeholder.  You  may  group  the  stakeholders  together  based  on 
their  position  in  the  organization  and/or  their  role  in  the  transfer. 

•  Ident^  stakeholder  frame  of  reference.  For  each  stakeholder  or 
stakeholder  group,  identify  why  they  should  support  the  transfer  and 
what  the  change  will  mean  to  them.  When  you  are  identifying  what  will 
and  will  not  change  for  each  stakeholder,  do  so  firom  their  frame  of 
reference,  not  from  yours. 

•  Understand  stakdiolder  relationships.  Consider  the  organizational 
structiue  scenarios  in  Figure  3-2  and  identify  which  one  applies  to  your 
situation.  The  following  list  describes  each  scenario  and  how  it  may 
impact  the  transfer  (Conner  1993). 

-  Scenario  I.  This  is  the  typical  hierarchical  organization.  The  sponsor 
may  successfully  cascade  some  sponsorship  duties  to  the  change 
agent  The  end  users  view  the  change  agents  as  an  extension  of  the 
sponsor. 

-  Scenario  2.  If  the  sponsor  delegates  sponsorship  duties  to  the  change 
agents,  the  end  users  are  more  likely  to  resist  For  this  structure  to 
be  successful,  the  sponsor  needs  to  emphasize  commitment  to  the 
transfer  and  introduce  the  change  agents  as  the  group  chosen  to  lead 
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End  User  ^^^ange  Agcnt^^ 

Scenario  3 

Figure  3-2  Role  Relationsh^ 


the  effort  This  demonstrates  sponsor  commitment  and  will  reduce 
the  end  users’  resistance. 

-  Scenario  3.  This  structure  poses  a  challenge.  If  Sponsor  A  and  the 
change  agent  want  any  glinuner  of  success,  they  must  convince  the 
end  users’  sponsor,  Sponsor  B,  that  the  transfer  is  imperative. 
Until  this  is  accomplished,  the  end  users  will  resist 

*  Develop  an  itrfluence  campaign.  Prepare  a  formal  and/or  informal 
influence  campaign.  The  theme  of  the  campaign  should  highlight  how 
the  transfer  will  satisfy  the  needs  of  the  organization  and  how  to  get 
the  organization  to  support  the  transfer.  The  campaign  should: 

-  Determine  when  each  stakeholder  should  be  approached  to  “talk 
up”  the  transfer,  given  the  stakeholder’s  role  in  the  transfer  and  the 
way  decisions  are  made  in  your  orgam'zatioa 

-  Explain  why  each  stakeholder  should  use  the  new  technolc^  and 
what  the  impact  is  on  them.  Your  arguments  must  include  near- 
term  as  well  as  long-term  implications  of  using  the  technology. 

-  Describe  the  logistics  approach,  including  who  will  deliver  the 
message,  how  it  will  be  delivered,  frequency  of  the  publicity,  and 
in  what  order  the  stakeholders  will  be  approached. 

-  Be  clear  and  honest  about  the  technology  and  the  transfer  process, 
including  training  and  support.  Have  satisfied  users  talk  with  new 
users  to  allay  their  concerns.  Describe  when  the  transfer  will  be 
taking  place  and  when  it  will  be  affecting  each  stakeholder  group. 
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3.  Look  at  Your  Situation:  Understand  Context 

In  your  campaign,  use  your  informal  network  (the  “grapevine”)  as  early 
and  as  often  as  it  makes  sense  to  build  up  awareness  and  support  for 
the  transfer.  Be  honest  but  upbeat  about  the  impacts  and  benefits  of 
the  technology.  Operate  the  campaign  cm  both  informal  and  formal 
fronts.  For  example,  campaign  in  quiet  meetings  over  lunch. 

Cycle  2  Using  the  influence  strategy  you  developed  in  Cycle  1,  get  buy-in  &om  the 

stakeholders.  You  may  need  to  modify  the  influence  strategy  based  on  the 
results  of  Cycle  1. 

Cycle  N  Throughout  the  transfer,  you  need  to  continuously  sell  the  transfer  and 
influence  others  to  buy  in  to  the  transfer.  This  wiU  help  the  success  of  the 
transfer  and  will  make  your  commitment  milestones  easier  to  achieve.  As 
you  obtain  lessons  learned  throughout  the  transfer,  or  as  your  environment 
changes,  you  should  update  yoiur  influence  strategy  accordingly. 

Example  3-1  describes  how  (me  manager  had  to  initiate  a  bothxn-up 
campaign  to  influence  his  managers  to  transfer  a  tecluM^ogy. 


J.  P  Heartless,  the  manager  of  the  Advanced  Technology  Group  (ATG)  at  Defenseless 
Systems  has  responsibility  for  the  transfer  oi  an  advanced  software  system,  known  as 
SMAK-B.  SMAK-B  was  devetoped  at  considerable  company  expense,  and 
management  would  like  to  see  some  payback  from  internal  transfer.  The  system  is 
colloquially  referred  to  as  a  “Super  Macro-processor  with  a  Knowledge  Base.”  These 
macros  can  access  powerful  pattern  matching  capabilities  that  make  SMAK-B  ideal 
for  building  sped^tion  languages  that  can  automatically  generate  applications 
software  and  construct  language-to-language  translators. 

After  experiencing  less  than  limited  success  explaining  the  system  to  senior 
management  in  various  divisions.  Heartless  adepts  a  somewhat  different  approach  to 
influencing  transfer  decisions.  Using  informal  and  social  networking  techniques,  he 
identifies  several  engineers  who  have  a  problem  that  is  amenable  to  a  SMAK-B  based 
solution.  Heartless  works  with  each  engineer  to  develop  a  rapid  prototype  of  a  solution 
that  demonstrates  the  ctqrability  of  SMAK-B  in  a  context  that  will  be  understandable 
by  the  engineer's  supervisors.  For  example,  in  just  a  few  days  one  of  his  staff  has 
worked  with  an  application  engineer  (Mr.  S.  Northon  Sniffle)  to  build  a  system  that 
will  automatically  construct  test  programs  for  an  advanced  but  highly  minaturized 
missile  system. 

Once  the  prototype  is  functioning  adequately.  Heartless  and  Sniffle  schedule  a 
meeting  with  the  (Edgar  Wheeze)i  intent  is  to  win  ^proval  for  widespread 

and  permanent  adoption  of  SMAK-B  as  the  solution  to  the  pr^lem.  This  interaction 
is  supported  by  results  the  r^id  prototype  and  the  testimonial  support  of  the 
engineer.  Wheeze  agrees  with  Sniffles  recommendation  and  the  transfer  proceeds. 

This  kind  of  “bottom-up”  approach  is  replicated  elsewhere  and  results  in  numerous 
and  positive  transfer  decisions  in  various  divisions  in  the  company. 


Example  3-1.  A  Case  of  a  Bottom-Up  Influence  Approach 
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3.  Look  at  Your  Situatioa:  Understand  Coated 

Stcmp  Cmtema 


You  will  stop  this  activity  when: 

•  You  have  identified  sponsors,  champions,  change  agrats,  and  end 
users  and  understand  their  readiness  and  willingness  to  support  the 
transfer 

•  You  have  prepared  an  influence  strategy 
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3.  Loot  at  Youf  Situation:  Understand  Conleii 


3^  DEFINE/UPDATE  TRANSFER  STRATEGIES 


This  activity  begins  in  Step  1,  Understand  Context. 


OVSKVIKW 

Your  objectives  in  ttm  activity  are  to  develop  transfer  and/or  cycle 
objectives,  alternative  strategies,  and  constraints  and  identify  alternative 
technologies  that  are  amsistent  with  the  needs  and  current  environment 
of  your  organization. 

In  this  activity,  you  may  provide  retrospective  validation  for  decisions  that 
have  already  been  made.  It  is  also  especially  important  that  you  document 
your  progress  in  this  activity,  since  your  situation  may  change  rapidly  or 
be  perceived  differently  by  differmt  people. 

The  first  two  tasks  in  this  activity,  together,  represent  an  extensive 
examination  of  your  environment  Given  your  current  situation  (e.g.,  the 
technology  is  already  selected,  limited  resources  to  perform  examination), 
you  may  want  to  prioritize  these  tasks  and/or  onfy  brieffy  touch  on  some 
of  them.  However,  each  task  discusses  an  area  that  can  impact  the  transfer 
and  should  therefore  not  be  completefy  skipped. 


Start  Criteria 

You  should  try  to  use  information  that  is  already  available  and  supplement 
it  with  information  that  you  solicit  from  interactions  with  users,  peers,  pro¬ 
ducers,  and  the  research  and  development  community.  You  should  use  the 
following  fypes  of  information  and/or  knowledge  as  inputs  to  this  activity: 

•  Internal  environment  information,  including  any  strategic  plans, 
process  improvement  documents,  descriptions  of  computing  facilities, 
and  anafysis  of  your  organization’s  work  force  (e.g.,  skills) 

•  External  environment  information  including  existing  organizational 
documents  on  technologies  (e.g.,  trip  reports,  benchmark  studies); 
market  surveys;  comparismi  data  with  peer  organizations;  competitor 
information;  and  relevant  laws,  regulations,  or  standards 

•  If  a  amtinuing  transfer,  the  transfer  planning  documents  created  and 
updated  in  previous  cydes,  induding  tte  transfer  plan,  risk  managnnent 
plan,  implementatitm  plan,  and  infhioice  strategy 

•  Any  historical  transfer  information 
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You  will  examine  external  and  internal  environments  for  potential  influoices 
on  the  transfer;  understand  the  reason  for  the  transfer,  define  the  transfer 
and/or  cycle  objectives,  alternative  strat^ies,  and  constraints;  appro¬ 
priate,  identify  technology  alternatives;  and  idoitify  a  strata  for  how  to 
proceed  with  the  transfer. 

1.  Examine  External  Environment,  lb  define  an  effective  transfer  strategy, 
you  need  to  examine  your  external  environment  to  identify  potential 
influences  on  the  transfer. 

This  task  provides  guidance  for  an  extensive  examination  of  your 
environment.  If  you  are  limited  on  resources,  then  you  may  want  to  priori¬ 
tize  the  areas  you  examine  and/or  only  briefly  touch  on  some  of  them.  How¬ 
ever,  each  area  discussed  can  impact  the  transfer  and  should  therefore  not 
be  completely  skipped. 

CycJe  1  In  the  first  cycle,  you  need  to  examine  your  external  environment  to 
understand  what  can  impact  the  transfer.  You  need  to  examine  your  cus¬ 
tomers,  markets,  suppliers,  and  related  government  policies  and  actions. 

•  Customers.  Your  customers  are  the  most  important  factor  in  your 
external  environment.  You  need  to  understand  any  impact  the  transfer 
will  have  on  the  customer.  For  example,  you  may  be  changing  the  way 
you  send  out  engineering  updates  or  the  way  you  determine  customer 
requirements.  If  the  technology  does  change  a  customer  interface,  then 
you  need  to  talk  with  the  customer  and  inform  them  of  the  pending 
change,  including  the  expected  impact,  benefits,  and  time  frame.  In 
this  discussion,  you  should  get  your  customer’s  feedback  on  the 
change. 

If  your  customers  have  problems  with  the  change,  then  you  should 
consider  changing  your  strategy  or  technology  based  on  the  customer 
requests  or  else  identify  their  problems  as  risks  and  mitigate  these 
risks  by  continuing  to  involve  the  customers  in  your  decision-making 
and  influence  strategy  activities. 

•  Markets.  You  need  to  understand  bow  the  transfer  will  affect  or  be 
affected  by  your  organization’s  market  base.  For  example,  you  may 
plan  on  bringing  in  a  technology  that  represents  a  substantial  invest¬ 
ment  in  a  single  market  that  your  senior  management  may  not  want 
to  make  (e.g.,  a  tool  that  supports  a  standard  soon  to  be  obsolete). 


lb  determine  market  impacts,  you  need  to  look  at  strategic  and  technical 
plans  and  talk  to  senior  management  to  understand  whether  there  are 
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^  End  User 
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3.  Look  at  Your  Situation:  Undewtond  Coniext 


any  market  changes  that  might  affect  the  transfer.  You  should  factor  their 
comments  in  as  techndogy  requirements,  transfer  objectives,  transfer 
constraints,  and/or  transfer  risks. 

Example  3-2  shows  how  a  change  in  customer  base  affected  the 
technology  directions  of  one  company. 

Boss  Systems  is  near  the  end  of  an  organization-wide  effi»t  to  inqdement  a  new 
software  development  process  that  is  oonfigored  to  meet  the  specifications  ci  its 
DoD  contracts,  wfiich  aoooant  for  almost  3/4  of  Boss  System’s  business.  The 
process  includes  such  mandatory  items  as  risk  management  plans  and  lays  the 
groundwork  for  integrating  measurement  and  quality  programs  in  order  to  move 
up  to  a  Level  3  on  the  SETs  CMM  within  the  next  3  years. 

Because  the  process  is  new,  management  and  staff  are  dhnbing  learning  curves 
that  are  (hc^fiilly  temporarily)  causing  overhead  rates  to  qpike.  It  is  hoped  that 
these  initial  costs  will  be  paid  for  later  in  the  software  life  qwle  as  development 
and  mainterrance  costs  decrease. 

Unexpectedly,  Boss  lands  a  large  commercial  contract  with  General  Motcns  that 
is  sch^led  to  begin  in  30  days.  The  proposal  was  bid  before  the  feu  impact  of 
the  new  software  devek^ment  process  was  understood;  therefcue,  overhead  rates 
and  schedules  were  bid  usingdata  learned  from  the  previous  process.  Strat^pcaQy, 
the  GM  contract  is  crucial  since  it  holds  the  prospect  of  making  up  for  erqiected 
declines  in  DoD  business  over  the  next  few  years. 

Top  management  decides  tliat  GM  must  be  satisfied  regardless  of  the  cost 
implications  for  the  comjmny  and  the  project  decides  to  go  back  to  the  old  process 
with  hopes  of  integrating  the  concepts  of  the  new  process  incrementally.  Senior 
management  sees  this  as  a  major  step  backwards  in  improving  the  company’s 
software  development  process. 

Example  3-2.  A  Case  of  New  Customer  Impacts 

•  Suppliers,  Suppliers  are  those  producers  that  provide  technologies  or 
services  to  your  organization.  Th^  include  consultants  and  hardware 
and  software  vendors.  When  you  bring  in  a  new  technology,  you  are 
potentially  forming  new  supplier  relationships  and/or  impacting  exist¬ 
ing  supplier  relationships.  For  example,  you  may  bi^  a  technology 
from  a  new  supplier  that  was  available  from  an  existing  supplier.  You 
need  to  understand  whether  your  organization  has  any  strategic 
alliances  with  existing  suppliers  that  will  impact  the  transfer  or  the 
technology  you  sel^t  for  the  transfer.  You  need  to  incorporate  these 
factors  into  the  technology  requirements,  transfer  constraints,  and/or 
transfer  risks. 

•  Government  Policies  and  Actions.  Government  policies  and  actions, 
both  current  and  future,  are  important  in  many  technologies.  You  need 
to  examine  the  policies  and  actions  related  to  the  technology  and  the 
transfer  and  understand  the  risks  associated  with  compliance  or  non- 
compliance  to  the  policies.  You  need  to  discuss  these  issues  with  your 
sponsors  and  other  senior  managers  to  understand  any  organizational 
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3.  Look  al  Your  Sitiwlion:  Undenland  Con  tea 


compliance  requirements.  This  is  (me  area  in  which  pe(^k  idx)  w(^ 
in  or  have  previous  experience  with  the  government  can  be  very  he^fuL 
Example  3-3  shows  how  government  actions  significantly  affected  an 
organization’s  technology  needs  directions. 


Tank  Builders,  Incorpcu^ted  (TBIX  a  major  DoD  sui^lier,  bases  40%  ils  business 
on  building  a  major  component  for  the  Ml/Al  tank.  The  company  has  been 
mfinmed  that  the  production  rate  of  this  vehicle  will  be  cut  in  half  within  18  months 
unless  major  international  orden  are  received.  TBI  has  also  been  informed  by  the 
Army  lhnk>Automotive  Command  that  it  will  need  to  be  CALS-compliant  in  all 
of  its  documentation  within  the  next  12  months  or  be  threatened  with  further  loss 
of  business. 

As  a  component  sui^lier,  IBI  was  in  no  position  to  influence  the  purdiase  of  tanks. 
Consequently,  the  decision  was  made  to  become  CALS-compliant  as  an  avenue  to 
increasing  business  with  the  government  in  other  areas. 

Internally,  organizational  changes  were  made  that  were  consistent  with  the 
introduction  of  CALS.  For  example,  a  supplier  development  function  was  created 
to  provide  assistaiKe  to  suppliers  to  help  them  become  CALS-compliant  This 
assistance  iixduded  both  finandal  help  with  technology  purchases  and  direct 
technical  he^  with  training  and  consulting 

Since  the  assistance  was  low  cost  to  the  suppliers,  the  strategy  was  successful  in 
bringing  them  up  to  foil  CALS-compliance  in  the  necessary  time  period. 


Example  3-3.  A  Case  of  (jovemment  Impacts  on  Ifechnology  Directions 


Cycle  2...N  In  subsequent  (^cles,  you  will  need  to  update,  as  necessary,  your  external 
environment  examination  based  on  the  results  of  previous  cycles. 


2.  Examine  Internal  Environment.  You  need  to  l(X)k  at  your  organizational 
culture  and  environment  to  understand  those  areas  that  will  impact  and 
be  impacted  by  the  transfer. 


Cycle  I  In  the  first  cycle,  you  need  to  examine  your  internal  environment  to 
understand  your  organizational  culture  and  what  organizational  struc- 
tiures  are  in  place  that  will  support  or  hinder  the  transfer.  Specific  areas 
to  examine  include  the  following: 


•  Organizadonal  Cultare.  Assess  your  organization’s  culture  in  relation 
to  the  transfer  and  the  technology.  Is  the  technology  like  other  technol¬ 
ogies  used  within  the  organization?  Has  the  organization  undertaken 
changes  or  transfers  in  the  recent  past  that  have  failed?  Does  manage¬ 
ment  request  staff  input  and  feedback  on  technological  directions?  If 
you  answered  no  to  even  one  of  these  questions,  then  you  run  a  risk 
of  failure  because  there  are  discrepancies  between  your  organization’s 
culture  and  the  transfer  you  plan  to  make.  In  this  situation,  you  need 
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3.  Look  at  Your  Situation:  Umtenland  Coaiert 


Cycle  2...N 


to  devote  at  least  one  cycle  to  educating  all  levels  within  the  organiza- 
tion  on  the  transfer,  including  the  justification,  the  process,  the  tech¬ 
nology,  and  the  impact  on  each  st^eholder. 

•  Orgamzatumal  Strengths  and  Wedcnesses.  You  need  to  identify  the 
strengths  and  weaknesses  of  the  organizatitm,  especially  in  the  unit 
that  will  be  using  the  new  technology.  Is  there  strong  technical  knowl¬ 
edge?  Is  there  strong  leadership?  Does  management  have  good  ccHitrol 
over  the  organization?  You  should  capitalize  on  the  strengths  and 
accommodate  the  weaknesses  in  your  transfer  strategy. 

•  Business  or  Technology  Strategies.  You  need  to  identify  v^ther  there  is 
a  current  business  and/or  technological  strategy  that  supports  the 
technological  change.  For  example,  your  organization  may  have 
long-range,  product-line  plans  that  provide  a  business  need  for  the 
change.  If  the  transfer  and/or  technology  you  are  proposing  supports 
existing  strategies  or  plans,  then  management  is  much  more  likely  to 
approve  the  transfer.  If  it  does  not  support  existing  plans,  then  you  will 
have  to  plan  extra  time  to  make  a  cost/benefit  case  to  upper 
management 

•  Policies  and  Procedures.  You  need  to  identify  the  policies  and 
procedures  that  support  or  constrain  the  transfer.  For  example,  a 
poli<7  or  procedure  may  require  the  use  of  a  specific  technology  that 
you  plan  on  changing  with  the  transfer.  You  should  capitalize  on  those 
policies  and  procedures  that  support  your  transfer  in  your  transfer  and 
cycle  strategies  and  plans.  For  those  policies  and  procedures  that  con¬ 
strain  the  transfer,  you  need  to  include  time  and  effort  to  modify  and 
get  approval  on  the  modifications  in  your  transfer  and  cycle  plans. 

•  Existing  Stqipart  and  limning  Resources.  You  need  to  identify  whether 
your  organization  has  any  existing  training  and  support  fimetiems.  You 
may  not  use  them  in  the  transfer,  but  you  need  to  understand  Aether 
th^  impose  any  requirements  or  cmistraints  on  the  transfer  (see  the  De¬ 
fine  Implementation  Plan  activify  (m  when  to  use  vendor-supplied  versus 
intemalfy-supplied  training).  Are  you  required  to  use  internal  resources 
first?  )M11  they  impose  requirements  on  the  techndogy?  You  need  to 
factor  your  findings  into  yoin  strategy,  technology  requirements,  or  risks. 

•  Rewto'd  Programs.  A  good  reward  or  incentive  program  might  induce 
people  to  try  new  technologies  that  improve  current  practices  and 
should  be  capitalized  on  in  your  transfer  strategy.  If  there  is  no  pro¬ 
gram,  then  your  options  are  to  transfer  without  one,  include  a  transfer- 
specific  reward  program  in  your  plans,  or  lobby  your  management  to 
institutionalize  a  reward  program. 

In  subsequent  cycles,  you  need  to  update,  as  necessary,  your  internal 

environment  examination  based  on  the  results  of  previous  cycles. 


3.  Look  >t  Your  Situation:  Understand  Context 


3.  Understand  Reason  and  E^qpccted  Benefits  for  the  IWuisfer.  Ycni  need 
to  understand  the  reason  for  the  transfer  (the  problem)  and  the  expected 
benefits  before  you  can  define  the  transfer  (the  solution).  The  following  list 
explains  some  possible  reasons  why  a  transfer  is  needed  along  with  how 
each  reason  might  affect  the  transfer: 


•  Strategic-  or  maHxt-driven.  The  reason  for  the  transfer  is  to  support  a 
new  corporate  strategy  or  to  respond  to  changes  in  the  market.  In  this 
situation,  you  will  probably  have  adequate  resources,  but  will  have  a 
highly-visible  transfer  that  needs  to  show  early  successes. 

•  Internal  process  improvement  actum.  The  reason  for  the  transfer  is  to 
support  an  internal  process  change,  such  as  a  software  process  im¬ 
provement  effort.  In  this  situation,  you  will  likely  have  adequate  man¬ 
agement  sponsorship  but  will  have  to  fight  against  resource  constraints 
and  resistance  to  change  due  to  other,  simultaneous  changes. 

•  Technology  opportunity  or  need,  initiated  by  managemenL  The  reason  for 
the  transfer  is  that  management  sees  a  need  or  opportunity  (not  strate¬ 
gic  in  nature)  that  can  be  met  by  a  new  technology.  In  this  situation, 
you  will  have  to  spend  time  getting  user  bi^-in  to  the  transfer. 

•  Ikchnology  opportunity  or  need,  initiated  by  a  grass-roots  campaign.  The 
reason  for  the  transfer  is  that  staff  members  want  to  use  a  new  technol¬ 
ogy.  In  this  situation,  you  will  have  to  spend  time  selling  management 
on  the  benefits  of  the  transfer,  and  you  will  have  to  be  carefiil  that 
management  does  not  feel  threatened  by  a  grass-roots  campaign. 

Qcle  1  In  the  first  cycle,  you  need  to  imderstand  the  original  reason  for  and  the 
expected  benefits  of  the  transfer  bdbre  you  can  effectively  and  realisticalfy 
define  the  objectives  and  constraints.  You  should  document  the  reason  for 
the  transfer  and  use  it  when  defining  your  objectives,  constraints,  alternative 
strategies,  and  alternative  technologies.  You  should  incorporate  the  expected 
benefits  into  the  transfer  success  criteria  (see  Define/Update  Hansfer  Plan 
activity). 

Cycle  2...N  In  subsequent  cycles,  you  need  to  see  whether  the  progress  made  in 
previous  cycles  will  cause  you  to  revisit  your  understanding  of  the  reason 
or  expected  benefits  of  transfer.  Hiis  should  be  reflected  in  the  objectives, 
constraints,  success  criteria  and  alternative  strategies  for  the  current  cycle 
and  potentially  for  the  entire  transfer. 

4.  Define  Objectives.  Based  on  all  of  the  information  you  have  gathered 
on  the  transfer,  you  need  to  define  transfer  and  cycle  objectives.  Hransfer 
objectives  are  strategically  oriented  (e.g.,  institutionalize  the  technology 
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throughout  1  division  in  2  years  and  throughout  the  organization  in  4 
years).  Cycle  objectives  are  tactically  oriented  and  focus  on  the  objectives 
of  the  current  cycle  (e.g.,  train  projects  A,  B,  and  C  and  integrate  the 
technology  into  project  D’s  technical  environment  by  the  end  of  the  cycle). 

An  objective  is  the  intended  or  desired  result  of  a  course  of  action.  Use 
the  following  guidance  when  defining  your  objectives: 

•  Write  several  independent  objectives  instead  of  combining  everything 
into  one  statement.  Progress  is  more  easily  assessed  when  separated, 
and  tradeoff  analysis  is  easier  to  perform.  A  rule  of  thumb  is  that  each 
objective  may  be  met  independently  of  the  other  objectives. 

•  Objectives  should  be  measurable. 

•  Objectives  should  be  clear,  concise,  controllable,  and  realistic. 

•  Objectives  should  create  winning  conditions  for  all  stakeholders. 

Cycle  1  In  the  first  cycle,  identify  objectives  for  the  entire  transfer.  The  transfer 
objectives  need  to  be  consistent  with  why  the  transfer  is  taking  place,  result 
in  the  expected  benefits  of  the  transfer  being  achieved,  and  support  the 
goals  of  the  people  initiating  and  sponsoring  the  transfer. 

In  addition,  identify  cycle  objectives  that  focus  on  creating  a  technology 
transfer  strategy  and  plan. 

Cycle  2  Work  with  your  sponsor  to  refine  your  transfer  objectives  based  on  the 
results  of  the  previous  cycle. 

Identify  cycle  objectives  that  focus  on  getting  sponsorship  and  stakeholder 
buy-in  to  the  transfer  effort. 

Cycle  N  In  later  cycles,  you  will  revisit  the  transfer  objectives  based  on  the  results  of 
previous  (ycles  and  define  tycle  objectives  for  the  current  tycle.  Cfycle  objec¬ 
tives  need  to  be  consistent  with  the  transfer  objectives  and  result  in  progress 
being  made  against  the  transfer  objectives.  You  will  do  the  folkiwing; 

•  Compare  the  results  of  previous  cycles  to  the  overall  transfer  objectives 
to  determine  whether  the  expected  progress  was  made.  You  may  have 
to  modify  transfer  objectives  (e.g.,  expect  institutionalization  in  5  years 
instead  of  4  because  of  an  unexpected  reorganization). 

•  If  the  previous  cycle  did  not  make  the  expected  progress,  then  you  need 
to  define  cycle  objectives  that  make  up  for  that  lack  of  progress  while 
making  continued  progress  against  the  transfer  objectives. 
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5.  Identify  Alternative  Technologies.  You  need  to  perform  this  task  when 
you  and  your  organization  have  not  already  chosen  a  specific  technology. 
However,  in  many  transfers,  the  transfer  was  initiated  because  your  orga¬ 
nization  has  identified  a  specific  technology  to  transfer.  In  this  situation, 
you  should  still  follow  the  guidance  in  this  task  because;  you  want  to  make 
sure  that  the  technology  addresses  end  user  requirements:  there  may  be 
better  technologies  available  of  which  you  should  be  aware;  and  this 
guidance  will  help  identify  transfer  risks  due  to  the  technology. 

You  will  perform  this  task  in  parallel  with  the  Understand  Process  activity 
because  that  activify  will  help  you  understand  any  constraints  or 
requirements  imposed  by  the  current  process. 

In  this  task,  you  may  define  entire  technology  areas  first  (e.g.,  whether  your 
organization,  to  improve  productivity,  should  transfer  in  a  CASE  tool  or 
adopt  object-oriented  design  techniques)  before  you  narrow  down  to  a  spe¬ 
cific  technology  products  (e.g.,  specific  CASE  tools  or  object-oriented 
design  methods). 

It  is  critical  in  this  task  to  document  your  technology  selection  and 
rejection  decisions,  along  with  the  rationales,  because  you  may  be  asked 
to  defend  a  decision  at  a  later  date. 

Cycle  I  You  need  to  define  your  technology  requirements  and  identify  one  or  more 

technologies  that  meet  those  requirements.  Subtasks  include: 

•  Define  Technology  Sequirements.  You  need  to  define  a  set  of 

requirements  for  the  technology.  You  should: 

-  IMk  to  the  end  users  to  identify  which  technology  functions  and 
features  are  mandatory  and  which  are  optional  You  may  want  to  gen¬ 
erate  a  questionnaire  to  help  you  in  this  task.  This  questionnaire 
should  first  communicate  alternative  transfer  strategies  and  thm  ask 
the  user  to  communicate  the  typical  way  in  ^ch  they  work  in  that 
technology  area.  How  would  th^r  interact  with  the  technology?  How 
should  the  technology  help  them?  Are  there  other  technologies  or 
people  that  wOl  interact  with  the  technology? 

-  Define  technology  requirements  based  on  the  user  discussions. 
The  requirements  need  to  support  the  transfer  objectives. 

-  Prioritize  and  weight  your  requirements  so  that  they  take  into 
account  the  key  shortcomings  of  current  practices  and/or  the  k^ 
integration  areas.  In  other  words,  you  need  to  define  the  rank  order 
of  technology  needs  and  requirements.  Prioritized  requirements 
will  also  help  as  you  search  for  available  technologies. 
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Benchmarking  is  a  method  that  you  can  use  to  define  technologr 
requirements.  One  current  description  of  benchmarking  is  how  a  com¬ 
pany  compares  its  .  performance  on  critical  customer  require¬ 
ments  against  that  of  the  best  in  the  industry  (direct  competitors)  or 
class  (companies  recognized  for  their  superiority  in  performing  certain 
functions)  to  determine  what  should  be  improved”  (V^iziri  1992).  You 
can  use  benchmarking  results,  or  the  results  of  what  the  best  in  the 
industry  are  using  in  this  technology  area,  in  your  requirements. 
Additional  sources  on  benchmarking  are  Camp  (1989)  and  'tyson 
(1990). 

Example  3-4  fists  one  company’s  requirements  for  a  technology. 


3.  Look  at  Your  Situation:  Understand  Context 

in  this  subtask  is  to  identify  a  small  number  of  technology  alternatives 
that  you  will  analyze  closely  in  the  Analyze  and  Resolve  Risks  activity. 

-  Identify  what  technologies  are  available  in  the  marketplace  by 
reading  reports,  reviewing  product  evaluation  reports,  attending 
conferences,  and  talking  directly  to  producers  and  researchers. 
You  should  look  internationally.  You  should  identify  those  technol¬ 
ogies  that  address  the  technology  requirements  you  defined 
earlier. 

-  Select  a  small  number  of  technology  alternatives  to  look  at  more 
closely  in  the  Analyze  and  Resolve  Risks  activity.  The  alternatives 
you  select  should  meet  the  technology  requirements  and  best  fit 
your  organization’s  culture  and  ctirrent  practices.  The  actual  num¬ 
ber  of  alternatives  will  depend  on  your  situation;  however,  you 
should  tiy  to  keep  the  number  down  to  less  than  six,  and  ideally 
down  to  two  or  tluree. 


Cycle  2  In  Cycle  2,  if  your  sponsors  recommended  changes  to  the  technology 
selected  in  Cycle  1,  you  may  need  to  identify  other  technology  alternatives. 
If  so,  then  refer  to  the  guidance  given  in  Cycle  1,  changing  your  technology 
requirements  to  include  the  conunents  fi:om  the  sponsors. 

Cycle  N  In  subsequent  cycles,  if  the  transfer  has  had  problems  related  to  the 
selected  technology,  you  should  refer  to  the  guidance  given  for  Cycle  1  to 
identify  other  alternative  technologies  (possibly  including  oreviously  iden¬ 
tified  technologies  that  were  not  selected),  modifyini  your  technology 
requirements  to  address  the  problems  in  the  implementation. 

6.  Identify  Alternative  Strategies.  Based  on  all  of  the  information  you 
gathered  in  this  activify  and  the  Build/Reinforce  Sponsorship  and  Foimda- 
tion  activity,  you  need  to  identify  alternative  strategies  for  how  to  proceed 
with  both  the  transfer  and  the  cycle. 

The  sponsor  needs  to  participate  in  identifying  the  alternative  strategies.  If 
the  transfer  is  part  of  a  process  improvement  effort,  then  the  Process  Group 
should  participate  since  they  have  an  understanding  of  what  strategies  will 
and  will  not  support  the  overall  improvement  effort 

Cycle  1  You  need  to  identify  alternative  strategies  for  how  to  proceed  with  the 
transfer.  These  strategies  need  to  be  consistent  with  the  reason  for  the 
transfer  and  result  in  the  transfer  objectives.  Your  strategies  should  also 
ensure  short-term  successes  to  support  growing  impetus  for  the  change. 
Each  alternative  strategy  should  address  the  foUowing: 

•  When  to  Than^er.  You  can  get  your  sponsor  to  commit  to  the  transfer 
either  when  they  currently  have  a  technology  need  or  when  they  anticipate 
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that  they  will  have  a  techndogy  need.  Conner  (1993)  calls  this  “current 
pain”  versus  “anticipated  pain.”  If  the  organization  commits  too  early 
(early  “anticipated  pain”),  then  the  transfer  wiU  be  difGcult  to  implnnent 
because  it  is  difficult  to  convince  managers  to  devote  resources  to  the 
change.  If  th^  commit  too  late  (late  “current  pain”),  then  the  fuQ  bei^ts 
of  the  technology  cannot  be  reaped  because  a  windatw  of  opportunity  was 
missed.  You  need  to  try  to  time  the  transfer  so  that  the  transfer  will  be 
supported  and  the  maximum  benefits  of  the  technology  can  be  achieved 

•  How  to  Transfer.  The  primary  input  to  how  to  implement  the  transfer 
strategy  will  be  the  original  reason  for  the  transfer  identified  in  Iksk 
3  of  this  activity.  If  the  reason  is  coming  from  the  top  down,  then  you 
have  a  variety  of  options  for  where  and  how  to  start  the  transfer,  several 
of  which  are  listed  later  in  this  task.  If  the  reason  comes  from  the  staS, 
then  your  strategy  has  to  focus  first  on  showing  the  viability  of  the 
transfer  to  management  before  performing  it. 

For  most  technologies,  you  should  test  the  transfer  before  using  the 
technology  on  a  line  project.  Tbsting— whether  through  pilot  projects, 
beta  tests,  or  shadow  projects— allows  bumps  and  wrinkles  to  be 
smoothed  out  with  minimiun  fuss  and  impact  and  gives  you  time  to 
propagate  success  stories  throughout  the  organization,  leading  to 
increased  chances  of  success  when  transferring  on  a  wider  basis. 

However,  for  technologies  that  require  major  cultural  changes  (e.g.,  a 
quality  assurance  program  that  spans  multiple  divisions),  for  technolo> 
gies  t^t  are  not  easily  tested  on  a  trial  use  basis  (e.g.,  a  networking 
package  that  automatically  affects  everybody’s  workstation),  or  in  situ¬ 
ations  where  management  wants  to  see  an  immediate  result  on  a  spe¬ 
cific  line  project,  testing  may  not  be  possible.  In  these  cases,  the  num¬ 
ber  of  alternative  strategies  is  reduced  to  one,  or  just  a  few,  and  you 
need  to  make  sure  you  spend  extra  effort  selling  and  planning  the 
transfer  because  there  will  be  many  more  stakeholders  and  risks 
/olved. 

If  you  do  have  the  option  of  testing  the  technology  transfer  first,  the 
following  list  gives  you  several  options,  along  with  the  advantages  and 
disadvantages  of  each,  for  where  to  start  You  can  identify  your  alterna¬ 
tive  strategies  from  this  list  and  from  other  options  unique  to  your 
organization  and  situation. 

-  Start  on  a  Proposal  Effort.  Advantages  include:  the  project  is 
flexible  in  what  technologies  are  used  and  how  they  are  used.  If  the 
proposal  is  won,  the  company  is  committed  to  the  technology.  The 
major  disadvantage  is  that  no  immediate  benefits  are  reaped  from 
the  technology  so  you  may  lose  enthusiasm  from  other  projects. 

-  Start  on  a  New  Project.  Advantages  include:  the  project  is  flexible  in 
what  technologies  are  used  and  how  they  are  used,  and  there  is  often 
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cash  available  fra:  training  and  int^ratkxi  efforts.  Disadvantages 
include:  the  project  is  undergoing  other  changes  ami  may  react  n^* 
tively  to  a  percdved,  unnecessary  change;  and  it  may  take  a  while  fim 
benefits  of  the  new  techndogy  to  be  visible. 

-  Start  on  an  In-Progress  Project  in  Good  Shape.  Advantages  include: 
a  project  in  good  shape  often  has  the  resources  needed  to  transfer 
the  technology  and  o^n  has  a  good  staff  attitude.  Hie  biggest  dis¬ 
advantage  is  that  the  project  has  no  reason  to  use  the  technology. 

-  Start  on  an  In-Prog^ess  Project  in  Bad  Shape.  Advantages  indude: 
a  project  in  bad  shape  is  often  looking  for  any  help  and  would  be 
willing  to  use  the  technology;  and  management  is  often  willing  to 
expend  resources  to  help  out  projects  in  trouble.  The  major  disad¬ 
vantage  is  that  if  the  technology  does  not  help  the  project,  even  if 
it  is  not  due  to  the  technology,  then  enthusiasm  and  support  for 
future  use  of  the  technology  is  at  risk. 

-  Start  on  an  Important  Project  The  advantage  is  that  succeeding  on 
an  important  project  ensures  strong  management  support  for  con¬ 
tinued  transfer.  A  disadvantage  is  that  failure  on  an  important 
project  ensures  strong  management  aversion  against  the  transfer. 

Example  3-5  shows  how  one  company  planned  a  pilot  transfer  before 

planning  widespread  transfer. 


The  Maishall  Company  decides  to  transfer  a  system  of  networked 486  PCs.  Deq>ite 
the  fdct  that  the  task  seemed  easy,  Marshall’s  in-house  system  group  decides  to  pilot 
the  chosen  system  with  three  eeqierienced  users  within  the  company. 

Numerous  problems  are  uneiqrectedly  encountered,  particularly  with  the  cqradties 
and  flexibilities  of  the  networking  ^tures.  Ultimately,  it  is  discovered  that  the 
network  card  is  inadequate  for  the  intended  use,  and  the  system  is  reconfigured 
with  vendor  support  fallowing  these  changes,  a  successful,  wide^read  transfer  is 
achieved. 


Example  3-S.  A  Case  of  Piloting  a  Ihmsfer 

•  When  to  Publicize  "Wander.  You  need  to  identify  alternatives  for  when 
to  start  publicizing  the  use  of  the  technology  both  inside  and  outside 
the  organization.  A  strategy  might  be  that  an  early  announcement 
would  jeopardize  the  plan,  so  you  may  delay  publicity  until  the  decision 
has  been  made.  Conversefy,  to  rally  as  much  support  as  possible,  you 
may  publicize  the  transfer  earlier. 

You  need  to  identify  alternative  cycle  strategies  in  Cycle  1  that  focus  on 
working  with  the  involved  change  agents  and  champions  to  develop  a 
transfer  plan. 

Q/cle  2  Based  on  input  from  your  sponsors,  you  may  need  to  identify  new  alternative 

transfer  strategies  or  modify  the  transfer  stratqy  selected  in  Cycle  L 
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You  need  to  identify  alternative  cycle  strategies  in  Cycle  2  that  focus  on 
getting  sponsorship  and  stakeholder  buy-in  to  the  transfer. 

Based  on  the  results  of  the  previous  cycle,  you  need  to  identify  alternative 
strategies  for  how  to  proceed  with  the  current  cycle.  In  defining  your  alter¬ 
native  cycle  strategies,  you  need  to  be  amcemed  with  progress  made  in 
previous  cycles  and  current  stakeholder  support  levels. 


•  Progress  Made  in  Prerious  Qfcks.  Your  current  cycle  strategy  will  be 
heavily  based  on  the  progress  made  in  previous  cycles.  This  informa¬ 
tion  is  documented  in  the  transfer  plan.  If  the  expected  progress  was 
not  made  in  previous  cycles  (e.g.,  the  technology  is  not  making  the  ex¬ 
pected  impact  or  the  transfer  is  running  behind  scheduleX  then  you 
need  to  make  sure  you  define  strategies  that  address  or  make  up  for 
lack  of  progress  while  showing  continued  progress  against  the  overall 
transfer  objectives.  You  will  also  want  to  include  short-term  successes 
in  the  strategy  to  help  maintain  stakeholder  support. 

•  StakdioUer  Support  Levds.  Your  cycle  strategies  will  be  heavily 
impacted  by  the  current  support  level  of  the  sponsors,  champions, 
change  agents,  and  users.  If  they  are  upbeat  and  energetic  about  the 
transfer,  then  you  can  take  higher  risks  and  try  proceeding  faster.  If 
they  are  in  a  lull  and  excitement  over  the  transfer  is  low,  then  you 
should  focus  on  reaping  noticeable  benefits  from  the  transfer. 

Alternatives  for  cycle  strategies  that  you  need  to  define  include: 


•  Whether  to  stay  focused  on  the  current  end  user  group  or  move  on  to 
other  organizational  units 

•  Whether  to  stay  with  the  current  technology  or  start  looking  at  new 
technologies 

•  Whether  to  move  toward  institutionalization  or  keep  the  transfer  on 
a  more  limited  scale 


Based  on  the  results  of  the  transfer  to  date,  you  may  need  to  modify  your 
transfer  strategy.  If  so,  then  you  should  identify  alternative  transfer  strategies 
that  address  the  problems  encoimtered  in  the  implementatitm. 

7.  Identify  Constraints.  Constraints  are  unchangeable  considerations  that 
the  alternative  strategies  and  technologies  must  satisfy.  Your  constraints 
may  come  from: 

•  External  Irtfluences.  Look  at  your  examination  of  your  external 
environment  and  identify  those  groups  that  impose  expectations  or 
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constraints  on  either  the  transfer  strategy  or  the  technology.  An 
example  of  an  external  constraint  is  that  your  key  cusuuitfr  requests 
you  use  a  specific  design  method  on  the  software  you  provide  to  them. 

•  Internal  It^bances.  Look  at  your  examinatitHi  of  your  internal 
environment  and  identify  expectations  or  constraints  cm  either  the 
transfer  strategy  or  the  technology.  An  example  of  an  internal  con¬ 
straint  is  that  your  company  wants  to  bid  (Hi  a  proposal  that  requires 
use  of  a  specific  pr(x%ss  modeling  technique. 

•  Existmg  ThchnoU^fes.  L(X)k  at  the  understanding  of  the  current  process 
(see  Understand  Process  activity)  and  identify  any  processes,  hard¬ 
ware,  or  software  technologies  that  you  cannot  change  that  impose  a 
constraint  on  the  transfix  strategy  or  the  technology. 

Qtcle  I  In  Cycle  1,  identify  constraints  on  each  of  the  alternative  transfer  and  (^cle 

strategies  and  on  the  alternative  technologies. 

Ocfe  2  In  Cycle  2,  identify  constraints  on  the  alternative  (^cle  strategies.  If  there 
were  changes  to  the  transfer  strategy  and/or  to  the  selected  technology  and 
if  alternatives  were  identified  again  in  this  (^cle,  then  identify  constraints 
on  the  new  alternatives. 

Cycle  N  In  later  cycles,  identify  constraints  on  the  alternative  (ycle  strategies  and,  if 
needed,  (m  alternative  transfin-  strategies  and  technologies.  Identify  these  con¬ 
straints  by  reviewing  prior  ccHistraints  and  identifying:  those  constraints  that 
are  and  are  not  still  applicable  any  new  constraints  that  cropped  up  since 
the  last  cycle  (e.g.,  your  organization  had  a  restructuring  and  you  now  have 
to  deal  with  a  potential  loss  of  funding  and  any  new  constraints  due  to  new 
transfer  tasks  you  wQl  be  performing  (e.g.,  this  is  the  first  cycle  that  will  in¬ 
clude  training  so  you  will  want  to  include  ary  training-related  constraints). 
In  addition,  realize  that  strategies  and  technologies  selected  in  earlier  cycles 
tend  to  impose  constraints  cm  later  cycles. 


Stop  Ciuteiua 


You  are  done  with  this  activity  when: 

•  You  understand  your  external  and  internal  environments,  including 
why  the  transfer  was  started  and  the  ecpected  benefits 

•  You  have  defined  transfer  and/or  cycle  objectives,  alternative  transfer 
and/or  cycle  strategies,  and  constraints  on  those  alternatives 


If  needed,  you  have  identified  alternative  technologies,  along  with  the 
constraints  on  them,  that  should  be  considered  for  the  transfer 
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33  UNDERSTAND  PROCESS 


This  activity  begins  in  Step  1,  Understand  Context. 


Your  objective  in  this  activity  is  to  understand  the  current  process  to  be 
changed  the  new  techndo^.  You  need  to  understand  how  the  new  tech- 
ndogy  will  interface  with  other  techndogies,  with  current  pdides  and 
procedures,  with  the  stafi,  and  with  other  parts  of  the  (vganizatitMi. 

This  activity  will  be  conducted  in  parallel  with  IkskS,  Identify  Alternative 
Ihchnologies,  of  the  Define/Update  Hransfer  Strategies  activity. 


Start  Criteru 


You  should  use  information  and/or  working  knowledge  on  the  following 
items  as  inputs  to  this  activity: 

•  Internal  environmoit  informaticm,  including  organizational  and  project 
pdides  and  procedures  and  descriptions  of  oxnputing  facilities 

•  Hie  technology  requirements  and  list  of  alternative  technologies 

•  Ihmsfer  and  cycle  alternative  strategies,  objectives,  and  constraints 


Tasks 


You  need  to  understand  your  current  hardware  and  software  environment 
and  understand  the  current  process,  or  practices,  that  will  be  changed  by 
use  of  the  new  technology. 


1.  Understand  Hardware  and  Software  Environment.  If  the  technology  is 
hardware-  or  software-related,  then  you  need  to  look  at  your  current  com¬ 
puting  environment  to  understand  issues  associated  with  integrating  the 
new  technology  into  the  environment. 


Cycle  1  In  Cycle  1,  you  need  to  understand  in  general  terms  current  hardware  and 

software  support  for  the  technology  area  you  are  proposing  to  change. 
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I— » 

Does  your  organization  cunently  have  automated  support,  or  is  this  a  new 
area?  If  there  is  currently  support,  what  platform  does  the  supporting  tool 
run  on  and  with  what  other  hardware  or  software  packages  does  the  tool 
interface?  Will  this  impact  the  new  technology’s  interfaces? 

If  your  organization  currently  does  not  have  hardware  or  software  support 
for  the  technology  area,  then  you  can  use  this  as  a  selling  point  to  manage¬ 
ment.  If  there  is  support,  but  the  users  feel  it  is  inadequate,  then  you  need 
to  make  sure  that  the  inadequacies  are  reflected  either  in  the  technology 
requirements  or  in  the  transfer  risks  in  the  Analyze  and  Resolve  Risks  ac- 
tiviQr  (depending  on  whether  you  can  address  the  inadequacies).  You  can 
also  use  this  finding  as  a  selling  point  to  management.  If  there  is  adequate 
support,  then  maintain  that  support  with  the  new  technology  or  include 
potential  user  resistance  as  a  risk  item  because  the  users  will  not  perceive 
a  need  for  the  change. 

Cycle!  You  need  to  understand  the  integration  issues  associated  with  the 
technology  selected  in  Cycle  1.  Issues  you  need  to  address  include: 


•  ^11  cmrent  hardware  and  software  support  use  of  the  technology? 

•  Do  you  have  adequate  network  capacity,  disk  size,  computational 
power,  or  memory  space  to  support  the  technology? 

•  Is  there  an  interface  incompatibility  between  current  hardware  and 
software  and  the  technology? 

If  you  answer  no  to  any  of  the  above  questions,  then  you  need  to  include 
these  items  as  risk  items  in  the  Analyze  and  Resolve  Risks  activity.  Poten¬ 
tial  risk  aversion  strategies  would  be  to  modify  or  upgrade  the  incompat¬ 
ible  hardware  and  software  to  support  the  new  technology  or  modify  the 
hardware,  software,  or  interface  requirements  for  the  technology  (e.g., 
transfer  the  technology  in  standalone  as  opposed  to  integrated  mode). 

Cycle  N  In  subsequent  cycles,  if  the  transfer  had  problems  related  to  the  selected 
technology,  you  should  refer  to  the  task  guidance  for  Cycles  1  and  2  to  sup¬ 
port  a  possible  decision,  in  the  next  step,  on  whether  a  new  technology 
should  be  selected. 

2.  Understand  the  Current  Process.  You  need  to  understand  how  the  new 
technology  will  fit  into  the  staffs  everyday  work  routine,  including  the  effect 
on  organizational  policies  and  procedures. 

Defining  and  modeling  your  process  is  a  useful  method  for  undeistandiiw 
the  ci  ...  process.  Defining  and  modeling  allow  you  to  analyze  and  compare 
the  easting  process  to  the  proposed  process,  as  well  as  hdp  you  facilitate  a^i/ 
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training  on  the  techndogy  and  its  integration  into  the  process.  Refer  to  the 
Process  Definiiion  and  Modeling  Guiddxxjk  (Software  Productivity  Consor¬ 
tium  1992a)  for  help  on  defining  and  modeling  your  processes. 


Cycle  1  In  the  first  cycle,  you  need  to  understand  how  users  currently  work  in  the 
technology  area  you  are  prt^Msing  to  change.  Spedficalty,  you  need  to: 

•  Understand  whether  the  technology  area  is  consistent  with  your 
organization’s  current  culture  and  practices.  Is  the  technology  area  a 
major  deviation  from  the  way  the  organization  currently  works  (e.g., 
transferring  in  a  new  quality  assurance  program  with  supporting  tools 
when  none  was  previousty  in  place)  or  is  it  only  a  minor  deviation  (e.g., 
a  new  quality  assurance  tool  in  an  existing  quality  assurance  pro¬ 
gram)?  If  the  technology  is  inconsistent  with  current  practices,  then 
you  will  need  to  allocate  time  getting  management  and  staff  to 
imderstand  the  technology  so  that  they  will  buy  in  to  it. 

•  Understand  whether  the  technology  area  requires  a  major  or  minor 
change  in  daily  work  loads  for  the  end  users.  If  the  way  the  end  users 
will  perform  work  is  going  to  change  drastically,  then  you  need  to 
expect  high  selling  and  training  costs. 

•  Understand  whether  existing  technologies,  practices,  or  policies  and 
procedures,  which  you  may  not  be  able  to  change,  place  constraints 
on  what  new  technolo^es  may  be  adopted. 

If  you  generate  any  findings  that  can  negative^  impact  the  transfer,  then  you 
should  capture  the  findings  as  risks  in  the  Anatyze  and  Resdve  Risks  activity 
and  invest  at  least  one  ttycle  in  the  process  to  selling  the  users  on  the  bene¬ 
fits  of  the  technology.  See  the  task  ]hrepare  and  Implement  Influence  Strat¬ 
egy  in  the  Build/Reinforce  Sponsorship  and  Foundation  activity  for  help 
on  how  to  get  others  to  buy  in  to  the  transfer. 

Cycle  2  You  need  to  imderstand  the  process  issues  associated  with  the  technology 
selected  in  Cycle  1.  Answer  the  same  questions  that  you  did  for  the  first 
cycle  in  this  task,  focusing  this  time  on  the  selected  technology  and  how 
it  specificaUy  impacts  end  user  work  practices. 

Cycle  N  In  subsequent  cycles,  if  the  transfer  had  problems  related  to  the  selected 
technology,  you  should  refer  to  the  task  guidance  for  understanding  the 
current  process  to  support  a  possible  decision  in  the  next  step  on  whether 
a  new  technology  should  be  selected. 


Stop  Criteria 


You  are  done  with  this  activity  when  you  have  an  understanding  of  how 
your  technical  and  organizational  environments  will  change  because  of  the 
technology  you  are  proposing  to  transfer. 
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3.4  CONTEXT  REVIEW 


This  activity  begins  at  the  end  of  Step  1,  Understand  Contetct 


Your  objective  in  this  activity  is  to  get  omsensus  frcnn  all  stakehdders  on  the 
objectives,  alternative  strat^es,  and  ccmstraints  defined  iat  the  transfer  and/ 
or  for  the  current  (^de;  alternative  technologies;  and  your  understanding  of 
the  current  process. 


Start  Crtteru 


You  should  start  this  activily  i^en  you  have  defined  the  ccmtext  for  the 
transfer  and  (^cle  based  on  tl»  results  of  the  activities  in  Step  1,  Understand 
Context  You  need  to  have: 

•  'Q’ansfer  and  cycle  objectives,  alternative  strategies,  and  constraints 

•  Alternative  technologies,  if  applicable 

•  An  understanding  of  the  current  process  to  be  changed 

•  If  a  continuing  transfer,  the  transfer  plan 


Tasks 


You  need  to  get  consensus  fi-om  the  stakeholders  on  the  objectives, 
alternative  strategies,  and  constraints  defined  for  the  transfer  and/or  for 
the  current  cycle;  alternative  technologies;  and  your  understanding  of  the 
current  process.  In  this  activity,  you  need  to  get  stakeholder  input  on  your 
findings  from  the  Step  1  activities,  which  should  factor  into  your  risk  analy¬ 
sis  and  selection  activities  in  Step  2.  Through  performing  this  activity,  you 
will  increase  stakeholder  buy-in  to  the  transfer  since  th^  will  be  involved 
in  the  decision-making  and  analysis  activities. 

If  this  transfer  is  part  of  a  process  improvement  effort,  then  you  need  to 
get  review  and  approval  firom  the  Process  Group.  Depending  on  your  par¬ 
ticular  situation,  the  Process  Group  will  either  be  the  sponsors  or  the 
champions  for  this  transfer. 
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Cycle  1 


Cycle  2 


Cycle  N 


Cycle  1 
Cycle  2 


Cycle  N 


1.  Obtain  Agreement  FVom  Champions,  Change  Agents,  and  End  Users. 
The  focus  of  this  task  is  on  getting  agreement  from  the  champions,  change 
agents,  and  end  users  on  the  results  of  the  activities  in  Step  1,  Understand 
Context.  This  will  help  ensure  sponsor  support.  You  may  need  to  go 
through  several  iterations  of  reviews  before  they  agree. 

In  the  first  cycle,  you  wiU  be  getting  agreement  on  the  objectives, 
alternative  strategies,  and  constraints  for  the  transfer  and  the  current 
cycle;  alternative  technologies;  and  the  results  of  the  Understand  Process 
activity.  You  need  to  get  agreement  from  the  change  agents  and  champions 
involved  in  developing  the  transfer  plan. 

In  the  second  cycle,  you  need  to  get  agreement  on  any  modifications  to  the 
transfer  plan  and  the  cycle  objectives,  alternative  strategies,  and 
constraints.  You  need  to  get  agreement  from  the  change  agents,  cham¬ 
pions,  and  end  users  identified  in  the  Build/Reinforce  Sponsorship  and 
Foundation  activity. 

In  later  cycles,  you  will  be  getting  agreement  on  the  cycle  objectives, 
alternatives,  and  constraints  and  any  modifications  to  the  transfer  plan 
based  on  the  results  of  previous  cycles.  You  need  to  get  agreement  from 
the  change  agents,  champions,  and  end  users  identified  in  the  Build/ 
Reinforce  Sponsorship  and  Foundation  activity. 

2.  Obtain  Commitment  Firom  Sponsors.  After  you  have  agreement  from 
champions,  change  agents,  and  end  users,  you  n^  to  get  the  commitment 
of  the  sponsors.  You  will  usualty  do  this  through  a  series  of  presentations  to 
the  different  sponsors.  Depending  on  your  situation,  you  may  decide  to  stag¬ 
ger  the  presentations,  targeting  first  those  spmisors  ^o  are  more  supportive 
to  build  up  a  stronger  case  for  those  sponsors  who  are  less  supportive. 

You  may  have  several  iterations  in  your  presentation  to  management 
before  you  get  a  final  decision  to  go  ahead  with  the  implementation.  If  so, 
return,  as  necessary,  to  any  task  in  this  activity  or  in  the  other  activities 
in  this  step  to  get  the  decision  to  proceed. 

In  the  first  cycle,  you  will  not  perform  this  task  since  you  do  not  yet  have 
a  sponsor. 

In  the  second  cycle,  you  will  get  commitment  on  the  transfer  plan,  including 
the  objectives,  selected  strategy,  and  constraints;  the  selected  technology 
and  the  cycle  objectives,  alternative  strategies,  and  constraints.  You  need 
commitment  from  the  authorizing  and  reinforcing  sponsors  identified  in 
the  Build/Reinforce  Sponsorship  and  Foundation  activity. 

In  later  tycles,  you  will  get  commitment  on  the  cycle  objectives,  alternatives, 
and  constraints  and  any  modifications  to  the  transfer  plan  based  on  the 
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results  of  previous  cycles.  You  will  need  commitment  from  the  authorizing 
and  reinforcing  sponsors  identified  in  the  Build/Reinforce  Sponsorship  and 
Foundati(xi  activity. 


3.  Publicize  Commitment.  The  sponsors  need  to  publicize  their  support 
and  commitment  throughout  their  organization  to  keep  everybody  in¬ 
formed,  to  ensure  the  end  users  that  the  transfer  is  important,  and  to  help 
prepare  everybody  for  the  changes  ahead,  lb  publicize  their  support  and 
commitment  to  the  transfer,  the  sponsors  may  send  a  memorandiun  or 
electronic  mail,  hold  an  organization-wide  meeting,  or  hold  a  series  of 
briefings  across  the  organization. 

You  can  use  the  influence  strategy  developed  in  the  Build/Reinforce 
Sponsorship  and  Foundation  activity  in  plaiming  and  implementing  this  task. 

Cycle  1  In  Cycle  1,  you  will  not  perform  this  task  because  you  do  not  yet  want  to 
publicize  any  strategies  or  technologies  until  you  have  commitment  from 
all  stakeholders. 


Cycle  2...N  In  later  cycles,  you  should  work  with  the  sponsor  needs  to  publicize 
support  and  conunitment  to  the  transfer  to  help  prepare  everybody  for  the 
changes  ahead. 


Stop  Criteru 


You  should  stop  this  activity  when  you  have  buy-in  on  the  transfer  context 
from  the  stakeholders,  and  the  sponsors  have  publicized  their  support  and 
commitment  to  the  organization. 
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4.  CHOOSE  THE  RIGHT  PATH: 
ANALYZE  RISKS  AND  SELECT  STRATEGY 


Every  business  and  every  product  has  risks.  You  can’t  get  around  it. 

Lee  lacocca.  Chairman,  Chrysler  Corporation 


Section  Objectives 

1.  Provide  guidance  for 
analyzing  and  resolving 
the  risks  associated  with 
the  transfer 

2.  Provide  guidance  for 
selecting  the  best  strategy 
and  technology  for  the 
tranter 


After  you  have  identified  the  context  in  which  you  are  performing  the 
transfer,  you  need  to  understand  the  risks  associated  with  the  transfer  and 
cycle,  including  how  to  mitigate  the  risks,  and  identify  the  right  technology 
to  transfer.  Figure  4-1  shows  the  three  activities  described  in  this  section. 


Figure  4-1.  Analyze  Risks  and  Select  Strategy  Activities 


You  will  perform  the  Analyze  and  Resolve  Risks  activity  first,  the  Select 
Strategy  activity  ‘second,  and  the  Commit  to  Strategy  activity  last. 
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4.1  ANALYZE  AND  RESOLVE  RISKS 


This  activity  begins  in  Step  2,  Anafyze  Risks  and  Select  Strategy. 


Your  objective  in  this  activity  is  to  analyze  and  resolve  the  risks  associated 
with  the  identified  alternatives  for  the  transfer  strategy,  the  cycle  strategy, 
and  the  technology  to  be  transferred.  Hransfer  risks  are  at  the  strategic  lev¬ 
el  and  will  be  analyzed  in  the  first  cycle  and  then  reviewed  in  subsequent 
cycles.  Cycle  risks  are  at  the  tactical,  or  implementation,  level  and  will  be 
analyzed  in  each  (tycle.  Analyzing  technology  alternatives  will  be  per¬ 
formed  in  the  first  cycle  and  wiU  only  be  performed  again  if  there  was  a 
problem  in  the  transfer  related  to  the  technology  and  all  stakeholders  agree 
that  the  issue  of  which  technology  to  transfer  needs  to  be  revisited. 

In  this  activity,  you  will  concentrate  on  the  Actors,  or  risks,  that  may 
oppose  transfer  or  (tycle  success.  You  will  first  identify  and  analyze  risks; 
the  primary  result  of  this  analysis  is  a  quantified  list  of  risks  for  the  transfer 
and/or  the  ciurent  cycle.  After  identifying  and  quantifying  risks,  you  evalu¬ 
ate  possible  risk  aversion  strategies  and  commit,  plan,  and  execute  one  of 
those  strategies. 

Additional  guidance  on  risk  analysis  can  be  found  in  Charette  (1989)  and 
the  U.S.  Air  Force  (:W88). 


Start  Crtteru 


You  should  start  this  activity  when  you  have: 

•  Defined  and  approved  objectives  and  constraints  for  the  transfer  and 
the  cycle  that  all  stakeholders  support 

•  Alternative  transfer  and/or  (tycle  strategies  that  need  to  be  analyzed 

•  Alternative  technologies  that  need  to  be  analyzed,  when  appropriate 

•  If  this  transfer  is  part  of  a  process  improvement  effort,  then  any 
process  improvement  documents,  including  implementation  plans  and 
risk  management  plans 

•  An  understanding  of  the  current  process  and  computing  environment 
related  to  the  technology  area  being  changed 
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•  Supporting  documents,  including  any  organizational  pdicies  and 
procedures,  and  organizational  and  project  planning  documents 

•  Any  historical  technology  transfer  data 


You  will  perform  a  risk  anafysis  on  the  alternative  transfer  strat^es, 
alternative  (^de  strategies,  and  alternative  technologies  to  help  you  in  the 
next  activity  to  make  a  decision  on  which  strategy  and  which  technology 
to  use  for  the  transfer.  You  should  document  the  results  of  your  risk 
analysis  and  risk  aversion  plans  and  activities  in  a  risk  management  plan. 

Your  risk  management  plan  should  be  a  living  document  You  should  not 
just  concern  yourself  with  risks  once  in  a  c^cle  and  then  have  the  risk  man¬ 
agement  plan  sit  on  the  shelf  until  the  next  (^cle.  Rather,  you  should  keep 
on  top  of  known  risks  and  keep  your  ^es  open  for  new  risks.  Fbr  example, 
during  implementation,  a  key  player  may  leave  the  organization  or  you 
might  be  faced  with  a  restructuring— both  of  which  will  open  the  transfer 
up  to  new  risks.  Also,  keep  in  mind  that  most  serious  risks  are  people  risks 
(^ose  risks  related  to  people’s  reactions  to  the  transfer)  not  technical  risks. 

If  this  transfer  is  part  of  a  process  improvement  effort,  then  you  must  take 
into  account  the  objectives,  constraints,  risks,  and  action  plan  defined  and 
identified  for  the  larger  improvement  effort  when  you  are  identifying,  ana¬ 
lyzing,  and  averting  risls.  For  example,  if  there  are  multiple  transfers  oc¬ 
curring  in  parallel,  then  there  might  be  a  risk  of  inadequate  technical 
support  because  support  personnel  are  spread  too  thinfy. 

1.  Identify  and  Analyze  Risks.  You  need  to  identify  the  risks  associated 
with  the  alternatives  you  are  currentfy  looking  at,  estimate  the  potential 
chance  and  cost  of  each  risk  occurring,  and  then  evaluate  each  risk.  Each 
of  these  risk  analysis  areas  (identification,  estimation,  and  evaluation)  is 
summarized  in  the  following  list  before  guidance  is  given  on  specific  risk 
areas  for  technology  transfer.  References  are  provided  if  you  need  more 
information. 

•  Sisk  Idm^ficaUon.  Risk  identification  imcovers  and  categorizes  risks. 

You  can  use  the  following  methods  to  help  identify  risks: 

-  Risk  Source  ChetMsts.  These  checklists  remind  you  where  to  lo(^  for 
generic  and  project-  or  transfer-specific  items,  how  they  can  manifest, 
and  strategies  for  dealing  with  them.  Examples  are  provided  in 
Boehm  (1989),  U.S.  Air  Force  (1988),  and  Charette  (19W). 
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-  Assumption  Anafysis.  Boehm  (1989)  offers  a  sample  checklist  that 
helps  identify  optimistic  assumptions  about  the  ability  to  achieve 
some  result. 

-  Decomposition.  Poorly  defined  descriptions  of  what  has  to  be  done 
and  how  it  has  to  be  done  reveal  poor  understanding  of  tasks. 
Boehm  (1989)  offers  a  sample  checklist  to  help  identify  these  risks. 

Risk  Estimation.  Risk  estimation  calculates  the  probability  of  a  risk 

item  occurring  and  the  cost  of  it  occurring. 

-  Probability  of  Occurrence.  Establish  the  risk  rating  scales,  and  then, 
for  each  risk  item,  estimate  the  probability  of  occurrence  in  terms 
of  its  maturity,  complexity,  and  dependency.  Charette  (1989)  de¬ 
scribes  an  example  of  a  quantitative  risk  rating  shown  in  Figure 
4-2.  The  U.S.  Air  Force  (1988)  uses  another  rating  scale. 

Low  Minor  Moderate  Significant  Catastrophic 


.1  .3  .5  .7  .9 

Source:  Charette  (1989) 

Figure  4-Z  Example  Risk  Rating  Scale 

-  Cost  of  Occurrence.  Estimate  the  cost  of  each  risk  item  occurring 
in  terms  of  budget,  schedule,  and  product  qualify. 

Risk  Evaluation.  Risk  evaluation  helps  you  adequately  understand  and 

measure  the  risks  to  activefy  control  them.  Charette  (1989)  provides 

further  guidance  on  how  to  perform  the  following  tasks: 

-  Establish  Rtferent  Risk  Levels.  Predefine,  for  each  risk  item  and  for 
the  transfer,  upper  limits  of  acceptable  risk  for  each  time  phase 
of  the  transfer.  Overall,  transfer  risk  should  decrease  as  the  trans¬ 
fer  advances. 

-  Determine  Projects  Risk.  Calculate  each  item’s  risk  by  multiplying 
the  probabih'ty  of  occurrence  and  the  cost  of  occurrence;  do  this 
for  each  time  phase  of  the  transfer.  Calculate  the  transfer’s  average 
risk  by  averaging  together  each  item’s  risk. 

Understand  and  address  the  effect  of  risk  coupling  or  risk 
compounding.  Coupling  occurs  when  an  alternative  to  a  risk 
causes  another  risk  to  be  introduced  or  increased.  Compoimding 
occurs  when  the  risk  in  one  area  is  amplified  by  a  risk  in  another. 

-  Compare  Risks  to  Referent  Levels.  Identify  risk  items  that  ecceed  the 
upper  limits  of  acceptable  risk.  Identify  risk  items  with  a  signifi¬ 
cant  probability  or  a  significant  cost  of  occurring.  Compare  the 
transfer’s  average  risk  against  the  predefined  referent. 


Cyck  I 
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In  the  first  cycle,  you  are  looking  at  the  risks  associated  with  the  alternative 
transfer  strategies,  the  alternative  technologies  to  be  transferred,  and  tlK 
alternative  cycle  strategies. 

As  a  further  aid  in  identifying  risks,  this  guidebook  lists  potential  risk 
items  in  other  process  activities  in  which  you  would  first  become  aware  of 
the  risk.  These  risks  should  be  included  in  your  risk  management  plan. 

•  Bisks  of  Alternative  TYantfer  Strategies.  You  need  to  understand  the 
risks  associated  with  each  of  the  alternative  transfer  strategies.  For 
each  strategy,  you  need  to  look  at  the  following  risks: 

-  Impact  m  Stak^wlder  Practices.  You  need  to  understand  how  the 
stakeholders  perceive  the  transfer  strategy  firom  their  frame  of  ref¬ 
erence  in  terms  of  how  it  will  impact  their  day-to-day  work  and 
what  the  perceived  benefits  are.  Hie  higher  the  perceived  impact 
and  the  lower  the  perceived  benefits,  then  the  higher  the  risk  of 
failure. 

-  Onftict  WA  OAer  Efforts.  You  need  to  understand  other 
organizational  or  project  plans  or  efforts  that  will  affect  the  end  user 
groups  at  the  same  time  as  the  transfer  and  identify  risks  associated 
with  too  much  chaiige  occurring  at  once  and  constraints  (Xi  support 
resources.  Examples  of  other  efforts  include  a  corporate-level  pro¬ 
gram  or  effort  (e.g.,  a  qualify  assurance  program);  which  will  take  pre¬ 
cedence  over  project  or  division-level  efforts;  reorganizations,  which 
may  cause  you  to  lose  your  sponsors;  and  proposal  efforts,  which  will 
require  the  full  attention  of  the  end  users. 

-  Adequate  Time  and  Besources.  Determine  whether  the  strategy 
provides  adequate  resources  to  plan,  integrate  the  technology  into 
the  organization,  train,  sell,  and  support  the  transfer.  If  not,  then 
solicit  your  managers  and  the  transfer  sponsors  to  get  the  neces¬ 
sary  resources.  If  they  will  not  provide  the  resources,  then  indicate 
this  as  a  high  risk. 

When  assessing  risks  of  the  alternative  strategies,  revisit  the  success 
factors  identified  in  Section  2.3,  under  What  Makes  Ibchnology  Trans¬ 
fer  Successful?,  that  relate  to  the  organization,  the  end  users,  and  the 
change  agents  and  see  whether  the  strate^  supports  those  success  fac¬ 
tors.  For  example,  if  the  strategy  does  not  allow  adequate  time  for  the 
users  to  participate  in  the  planning  and  decision  making,  then  the 
transfer  runs  a  high  risk  of  failing  because  of  lack  of  end  user  buy-in. 

•  Bisks  of  Alternative  Technologies.  You  need  to  understand  the  risks 
associated  with  each  of  the  alternative  technologies. 


lb  understand  many  of  the  risks,  you  will  first  need  to  get  information 
from  each  technology’s  producer.  The  information  you  need  to  get 
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includes  support  upgrade  plans  and  major  development  plans;  sample 
documentation;  references  from  other  users,  particular^  those  in  a 
similar  environment;  technology  costs,  including  the  costs  for  the  basic 
product,  upgraded  versions,  and  transfer  mechanisms  (e.g.,  courses, 
hotline  support,  workshops,  and  consulting);  and,  whether  technical 
support  services,  such  as  training  and  a  hotline,  are  available  on  a 
regular  basis. 

For  each  technology,  you  need  to  look  at  the  following  risks: 

-  Impact  on  Stakeholder  Practices.  Understand  whether  the  tedindogy 
is  consistent  with  the  current  practices  of  each  stakehdder  group, 
from  their  frame  of  referooce,  and  with  your  organizatitm’s  techndo- 
gy  strategy.  If  not,  then  you  run  a  higher  risk  of  resistance  and  Mure 
and  will  need  to  spend  time  training  and  selling. 

-  Tkcdtung  and  StqtporL  Understand  any  risks  associated  with 
inadequate  training  and  support  Either  the  producer  or  your  organi¬ 
zation  will  have  to  provide  training  and  technical,  hotline  support 
when  the  technology  is  in  use.  You  need  to  make  sure  that  both  types 
of  support  are  adequate.  In  addition,  assess  the  quality  of  the 
documentation  to  see  how  well  it  will  help  the  support  efforts. 

-  Industry  Support.  Understand  whether  industry  provides  adequate 
support  in  terms  of  standards  or  tools.  The  more  prevalent  the 
teclmology  is  in  your  industry,  the  more  likely  it  will  be  supported 
by  industrial  standards  and  have  a  range  of  supporting  products 
from  producers. 

-  Integration.  Understand  whether  the  technology  is  compatible  with 
the  current  hardware  and  software  environment.  If  not,  then  you 
run  a  high  risk  of  not  being  able  to  integrate  the  technology 
smoothly  into  the  target  unit’s  daily  practices. 

-  Technology  Costs.  Compare  the  costs  of  the  technology  to  original 
projections  on  budget  for  purchasing  the  technology.  If  the  tech¬ 
nology  is  very  expensive  and  you  are  still  unsure  of  whether  it  is  the 
right  choice,  you  may  want  to  try  to  get  demonstration  or  evalua¬ 
tion  copies  to  test  on  the  projects  so  that  you  do  not  outlay  a  lot 
of  money  for  a  high-risk  venture. 

The  Technology  Benefits  Prototype  User  Manual  (Software 
Productivity  Consortium  1993c)  and  accompanying  tool  will  help  you 
estimate  the  cost  impact  a  new  tool  will  have  on  your  software 
development  process. 

-  Other  Hardware  and  Software.  Understand  whether  or  not  you  need 
to  purchase  other  hardware  and/or  software  to  support  use  of  the 
technology  and  whether  these  costs  will  cause  you  to  run  over  your 
budget  for  the  transfer. 
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-  Tailoring  Costs.  Understand  whether  there  are  tailoring  costs  that 
need  to  be  incuned  before  the  technology  can  be  used  and  how  this 
will  impact  the  schedule  for  the  transfer. 

-  Prior  Uses.  Gather  information  from  other  groups,  internal  and 
external  to  your  organization,  that  have  used  the  technology  in  the 
past.  They  may  be  able  to  share  lessons  learned  about  how  well  the 
technology  integrated  into  their  envir(nunent,  how  well  the  produc¬ 
er  supported  and  trained  the  users,  and  how  well  the  users  received 
the  technology. 

-  Cotuisiencf  with  Future  Trends.  If  there  is  an  identified  trend  that 
will  potentially  obsolete  certain  technology  alternatives  in  the  short 
or  long  term,  then  you  need  to  factor  that  into  your  selection,  lb 
identify  trends,  get  information  from  the  research  and  develop¬ 
ment  ^&D)  community  on  the  potential  for  substantial  changes 
in  technology  capabilities  in  a  short  time  firame.  In  addition,  look 
among  your  peers  for  attempts  to  improve  technology  and  practice 
and  identify  recurring  themes.  While  some  of  the  advanced  devel¬ 
opment  being  performed  by  competitors  or  producers  is  not  made 
pubhc,  other  R&D  work  is  readify  accessible.  In  addition,  you  can 
check  with  industry  analysts  who  track  technology  trends  across 
industries. 

Example  4-1  shows  how  one  organization  gathered  information  from 
vendor  and  research  communities. 

When  assessing  risks  of  the  alternative  technologies,  revisit  the  success 
factors  identified  in  Section  Z3,  tmder  What  Makes  Ibchnology  Hrans- 
fer  Successful?,  that  relate  to  the  technology.  For  mcample,  if  the  tech¬ 
nology  has  high  complexity  and  low  observabilify,  then  the  transfer 
runs  a  high  risk  of  failing  because  people  will  not  easily  see  its  benefit, 
and  you  will  need  to  spend  time  training  and  selling  management  and 
staff. 

When  performing  your  assessment  of  the  alternative  technologies, 
involve  suppliers  or  ctistomers.  For  mcample,  a  major  supplier  may  be 
just  as  interested  as  you  are  in  discerning  how  their  technology  stacks 
up  against  others.  In  addition,  they  might  be  willing  to  loan  you  free 
copies  of  their  tools  for  evaluation  purposes  hoping  that  there  wUl  be 
potential  sales. 

Risks  of  Alternative  Cycle  Strategies.  You  need  to  understand  the  risks 
associated  with  each  of  the  alternative  cycle  strategies.  Because  the  fo¬ 
cus  of  the  current  cycle  is  relatively  narrow— to  develop  a  transfer  plan 
and  get  approval  on  it  from  involved  change  agents  and  champions— 
your  primary  risk  areas  will  include  inabilify  to  define  a  transfer  plan 
soon  enough  because  of  other  change  agent  or  champion  commitments 
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Acme  Aeroq>aoe  has  deckled  to  upgrade  its  CASE  tool,  Justin  CASE  Acme  has 
been  a  successful  user  of  the  Justin  CASE  tool  for  10  years,  but  the  tool  is  showing 
signs  of  age  and  the  vendor  does  not  have  any  clear  upgrade  plans. 

As  the  first  step  in  the  search  for  technology  (q;>tions  in  the  CASE  toed  arena,  the 
president  of  Acme  put  Ed  Katz,  manager  for  software  devetopment,  in  charge  of  the 
search.  Ed  begins  to  amass  information  and  artifacts  fimn  several  available  sources. 
He  and  several  key  staff  members  attend  CASE  Erqra  Ed’s  assistant  reviews  selected 
journals  in  the  field  for  irtfonnation  about  both  the  state  of  the  art  and  the  state  of 
the  practice.  Ed  personally  visits  the  University  of  Houston,  Clear  Lake,  and  the 
Software  Engineering  Laboratmy  at  Maryland  to  discuss  recent  work  in  sui^rt  of 
NASA.  Technical  reports  from  other  research  organizations,  such  as  the  Strftware 
Productivity  Consortium,  ESPRIT,  and  the  SEI,  are  collected  and  reviewed.  The 
recent  products  and  efforts  of  the  Software  Tbchrtology  for  Adaptable  Reliable 
Systems  (STARS)  Program  are  reviewed  for  relevance. 

Ed  decides  to  irrvestigate  CASE  research  and  products  in  Rfestem  Europe  duough  his 
contacts  in  his  Bnissels  (^fioe.  Through  them,  Ed  hears  of  a  rumor  about  a  new 
intelligent  avionics  system  under  devek^oit  at  Airbus.  The  qfstem,  named  B^POOS 
(Primary  Automatic  POoting  Operatir^  On-line  System^  {Hovides  improved  aulcnnatic 
piloting  of  commercial  aircraft.  Mail  traffic  on  the  Usenet  discuased  how  this  system  was 
ooUaboratively  developed  by  software  professionals  in  three  countries  using  a  disttibutod 
CASE  system  devekped  jointly  by  Airbus  and  a  leading  CASE  vendor.  Ed  also  taDs 
with  a  gtotp  oi  researchers  at  Imperial  Ccdl^  in  the  UK.,  who  are  developing  seme 
interesting  next-generation  CASE  methodologies. 

Meanwhile,  two  d  Ed’s  associates.  Bin  Buttons  and  Terri  Marthin,  ludr  into  senne  very 
imenpected  treasures  in  technology  inteffigenoe.  BiD  Butttms  had  taken  his  dau^ter  to 
Spare  Camp  in  Huntsville,  AL  In  the  airport  bar.  Bin  runs  mto  a  software  engineer  fiom 
the  Unheisity  of  Houston,  Qear  Lake.  He  infixms  Bin  about  some  interesting  CASE 
tool  development  beit%  done  on  a  ^iority  basis  for  his  oompany,  BigCb.  As  it  turns  out, 
Terri  Marthin  is  an  old  college  roommate  of  asenior  software  engineer  from  BigCo.  Teni 
takes  her  out  for  dimter  and  receives  a  back-of-themrqddn  summary  of  BigCo’s  current 
strata  in  CASE  tools. 

Using  his  professional  contacts,  Ed  begins  to  line  up  a  select  list  of  knowledgeable 
CASE  consultants  who  can  provide  valuable  advice  and  assistance  to  the  selection 
and  implementation  process.  These  contacts  also  provide  some  feedbadc  on  their 
current  systems  and  personal  experience  that  cannot  generally  be  obtained  fiom 
other  sources.  After  the  field  was  narrowed  to  a  few  CASE  systems,  Ed  attends  some 
usergroup  meetings  for  these  systems  to  get  abetter  sense  of  howthese  systems  work 
and  how  they  are  currently  being  applied  within  similar  firms. 

As  a  result  of  his  research,  Ed  identifies  an  up-and-oomingCASE  company,  InCase, 
with  a  new  CASE  system  that  supports  the  same  principles  and  methods  of  their 
existing  CASE  system  (Justin  CASE)  whik  providing  flegdbility  to  adapt  to  a 
changing  CASE  market  Ed  spends  time  with  the  management,  marketing,  and 
development  staff  of  InCase,  and  they  decide  to  form  a  strategic  alliance  that  utilizes 
the  development  staff  of  InCase  and  the  knowledge  and  eaqrenence  of  ACME’S 
in-house  CASE  group.  Together,  they  develop,  field,  and  support  a  CASE  system 
that  for  ACME,  is  a  natural  evolution  fiom  Justin  CASE;  and,  for  InCase,  results 
in  a  system  that  is  tested  and  validated  in  the  large  aerospace  market 
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and  inability  to  find  enough  funds  to  support  definiti(»i  of  the  transfer 
plan. 


Cycle  2  In  Cycle  2,  you  will  identify  and  anafyze  risks  associated  with  any 
modificadcMis  to  the  transfer  plan  and  the  tedmcdogy  based  (w  sponsor  and 
stakeholder  comnents.  You  should  use  the  guidance  given  for  1  oi  diis 

task  to  perform  this  analysis. 

You  will  also  need  to  identify  and  anafyze  risks  associated  with  the  alteniative 
cycle  strat^es  for  obtaining  sponsorship,  framing  an  infrastructure,  and  get¬ 
ting  stakehdder  biy-in  to  the  transfer,  lb  identify  risks  in  these  areas,  kxdt 
at  the  guidance  the  Build/Reinforce  Sponsorship  and  Foundation  activity  on 
establishing  a  transfer  support  staft  assessing  end  user  readnea  to  change, 
and  identifying  sponsors.  If  your  situation  differs  from  the  guidance,  then  you 
should  identify  that  differ»ice  as  a  risk  and  anafyze  the  risk's  potential  impact 
on  the  transfer. 

Cycle  N  In  subsequent  cycles,  you  need  to  understand  the  risks  associated  with 
each  of  the  alternative  cycle  strategies.  For  each  strategy,  you  need  to  look 
at  the  following  risks; 

•  on  Staluholder  Practices.  You  need  to  uncterstand  how  the 
stakeholders  perceive  the  cycle  strategy  from  their  perspective  (their 
“frame  of  reference”)  in  terms  of  vhat  their  expected  rde  is  in  the  cycle, 
how  it  will  impact  thdr  day-to-day  work,  and  what  the  expected  benefits 
are. 

•  Cot^kt  Witit  OtiKr  ^orts.  You  need  to  understand  other 
organizational  or  project  plans  or  efforts  that  will  affect  the  aid  users  at 
the  same  time  as  the  cycle  and  identify  risks  associated  with  too  much 
change  cxxuiring  at  once  and  cemstraints  on  support  resources. 

•  A^quate  Time  and  Besources.  Determine  whether  the  cycle  strategy 
provides  adequate  resources  to  plan  the  cycle  and  perform  the  transfer 
activities  described  in  the  cycle  strategy.  If  not,  then  solicit  your  man¬ 
agers  and  the  U  ansfer  sponsors  to  get  the  necessary  resources.  If  they 
win  not  provide  the  resources,  then  cancel  or  delay  the  transfer  imtil 
this  issue  is  resolved. 

If  modifications  were  made  to  either  the  transfer  plan  or  the  selected 
technology  based  on  the  results  of  previous  cycles,  you  will  need  to  identify 
and  anafyze  risks  associated  with  the  alternative  strategies  or  technologies 
developed  for  addressing  the  modifications.  In  this  case,  you  should  use 
the  guidance  given  under  Cycle  1  for  this  task. 
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2.  Review  Risk  Aoalysis.  All  stakeholders  need  to  review  and  agree  to  the 
risk  anatysis  drme  in  Iksk  1  of  this  activity. 

Have  all  stakeholders  review  the  risk  analysis.  Incorporate  their  comments 
as  needed. 


Qfck 


3.  Evaluate  and  Plan  Risk  Aversion.  A  risk  aversion  strategy  attempts  to 
reduce  the  cost  and/or  probability  of  risk  occurrence  to  an  acceptable  lev¬ 
el.  Risk  aversion  strategies  generally  fall  into  oim  or  more  of  the  following 
categories: 

•  Aid  Risk  reduction  reduces  the  likelihood  of  a  risk  occurring 

and/or  the  magnitude  of  a  risk.  For  example,  you  may  extend  the  schedule 
of  the  transfer  if  you  have  a  hi^  risk  of  a  being  late. 

•  Risk  Protection.  Risk  protection  lessens  the  impact  of  a  risk  should  it 
occur.  For  example,  a  company  may  bid  many  proposals  to  protect 
itself  from  the  risk  of  current  contract  cancellation. 

•  Risk  Transfer.  Risk  transfer  reallocates  risk  to  areas  better  able  to 
handle  it  For  example,  you  may  transfer  responsibility  for  the  develop¬ 
ment  of  a  high  risk  so^are  component  to  a  project  more  capable  of 
handling  it 

•  Ksk  Contingency  FUnd.  A  risk  contingency  fund  establishes  a  reserve 
of  resources  to  compensate  for  risks  occurring.  For  example,  you  may 
build  some  slack  into  a  schedule  or  budget  to  accommodate 
unexpected  risks. 

•  Risfi  Acceptance.  You  may  accept  the  consequences  because  there  are 
no  cost-effective  strategies  for  risk  aversion. 

If  your  risks  are  too  high  and  you  have  no  cost-effective  aversion  strategies, 
then  you  may  decide  to  delay  the  transfer  until  some  of  the  risks  stabilize. 
However,  you  need  to  imderstand  and  analyze  whether  the  risks  associated 
with  making  or  continuing  the  change  are  lower  or  higher  than  the  risks 
of  waiting  until  later.  In  other  words,  is  it  crucial  to  make  the  change  now 
because  you  will  lose  your  competitive  edge  by  waiting?  Can  you  wait  until 
other  things  have  stabilized  or  until  the  technology  matures  or  is  tailored, 
increasing  your  chances  of  success? 

Qfcle  1...N  You  need  to  identify  risk  aversion  strategies  and  examine  the  impact  of 
each  strategy  on  the  risk(s)  that  you  are  attempting  to  avert  You  need  to 
document  and  identify  the  costs  and  schedule  of  each  strategy.  You  also 


^  Sponsor 


Change 

Agent 


Champion 


ft 


End  User 


4-10 


■^9 

r 

4.  Choose  the  Right  Path:  Analyze  Risks  and  Select  Strategy 

need  to  make  sure  that  the  resources  called  out  in  the  risk  aversion  plan 
are  consistent  with  the  resources  available  for  this  cycle.  However,  if  you 
need  additional  resources  to  avert  risk,  then  you  may  need  to  devote  the 
rest  of  this  cycle  to  risk  aversion  activities. 

Example  risk  aversion  strategies  for  technology  transfers  include; 

•  'E)  reduce  the  risk  that  the  technology  does  not  address  end  user  needs, 
use  an  outside  consultant  to  poll  the  end  users  to  determine  their 
technology  requirements. 

•  'C)  reduce  the  risk  of  selecting  the  wrong  transfer  or  t^cle  strategy,  pilot 
the  technology  using  different  transfer  strategies  to  see  which  strategy 
is  the  most  successful 

•  lb  reduce  the  risk  of  not  understanding  the  impact  of  the  technology 
on  the  end  users,  study  the  work  habits  of  the  target  unit  for  1  month 
before  defining  the  technology  requirements  and  the  transfer  strategy. 

•  lb  reduce  the  risk  of  not  having  stakeholder  buy-in,  spend  multiple 
qrcles  ensuring  that  you  have  the  complete  buy-in  of  all  stakeholders. 

•  lb  reduce  the  risk  of  rumors  starting  about  the  transfer  before  you  can 
adequately  allay  staff  concerns,  delay  publicizing  the  transfer  imtil  the 
results  of  a  pilot  project  can  clearly  show  the  benefits  received. 


$ 


4.  Commit  to  Risk  Aversion  Plan.  All  stakeholders  need  to  review  and 
agree  to  the  risk  aversion  plan  developed  in  Iksk  3  of  this  activity. 


Q^cle  I...N  You  need  to  solicit  the  commitment  of  all  stakeholders  on  the  risk  aversion 
plan  that  you  developed  in  the  previous  task,  incorporating  comments  as 
appropriate.  Since  risk  aversion  strategies  can  require  a  substantial  num¬ 
ber  of  resources,  it  is  important  that  all  stakeholders  agree  that  the  aver¬ 
sion  strategies  adequate^  address  the  risks,  that  they  do  not  incur  new 
risks  or  impact  other  risl^,  and  that  the  assigned  schedule  and  budget  are 
adequate. 


5.  Execute  Risk  Aversion,  lb  mitigate  the  transfer  and  technology  risks, 
you  need  to  execute  the  risk  aversion  activities  defined  in  the  approved  risk 
aversion  plan. 


^  Sponsor 


Change 

Agent 


Champion 


fL  End  User 

9 


4.  Chooae  the  Right  Mh:  Analyze  Riaks  and  Seicq  Statear 


Cyck  L..N 


You  perform  the  risk  aversimi  activity(ies)  outlined  in  the  approved  risk 
aversion  plan.  For  a  risk  aversion  activity  that  requires  a  large  amount  of 
resources,  you  may  want  to  devote  one  or  more  cycles  or  even  spin  off 
another  process,  or  spiral,  to  complete  it  Depending  on  the  risk  aversion 
strategy  being  performed,  you  may  need  to  involve  the  users  and 
champions. 


Stop  Crtteiua 

You  should  stop  this  activity  when  you  have  identified,  analyzed,  and 
averted  risks  related  to,  when  appropriate,  the  alternative  transfer 
strategies,  alternative  cycle  strategies,  and  alternative  technologies. 
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4.2  SELECT  STRATEGY 


Start  Crtteru 


This  activity  begins  in  Step  2,  Analyze  Risks  and  Select  Ibchndogy. 


Your  objective  in  this  activity  is  to  select  a  transfer  and/or  cycle  strategy 
and,  when  appropriate,  a  technology  to  use  in  the  transfer.  Your  selectitHi 
will  be  based  on  your  transfer  and  cycle  objectives  and  constraints,  your 
understanding  of  the  process  to  be  changed,  and  your  anatysis  of  the  risks 
associated  with  each  of  the  identified  alternatives. 

You  need  to  create  an  electronic  or  paper  trail  in  this  activity  to  help  you 
justify  and/or  explain  your  reasons  for  selection  or  rejection  at  a  later  date. 


Use  information  and/or  working  knowledge  of  the  following  items  as 

inputs  to  this  activify; 

•  Defined  and  approved  objectives,  alternative  strategies,  and 
constraints  for  the  transfer  and  the  cycle  that  all  stakeholders  support 

•  When  appropriate,  the  technology  requirements  and  the  alternative 
technologies  identified  in  the  Define/Update  Transfer  Strategies 
activity 

•  Your  understanding  of  the  current  process  and  computing  enviroiunent 
related  to  the  technology  area  being  changed 

•  Risk  analysis  results  for  the  transfer,  qrcle,  and  technology 


Tasks 

You  will  select  the  reconunended  transfer  and/or  cycle  strategy  and  the 
recommended  technology. 

1.  Select  a  IVansfer  and/or  Cycle  Strategy.  Based  on  your  approved 
transfer  and  cycle  objectives  and  constraints,  the  alternative  strategies 


Sponsor 


Change 

Agent 


Champion 


ft 


End  User 


4-13 


4.  Choose  the  Right  ftiUi:  Analyze  Risfcs  and  Select  Strategy 


identified,  and  the  risk  analysis  done  in  the  Analyze  and  Resolve  Risks 
activity,  you  need  to  select  a  reconunended  strategy  for  the  transfer  and 
the  cycle.  You  will  need  to  document  why  you  selected  one  strategy  over 
the  others. 

Cycle  1  In  Cycle  1,  you  will  select  a  strategy  for  the  transfer.  You  will  also  select 
a  cycle  strategy  that  focuses  on  how  to  get  the  transfer  plan  developed. 

Cycle  2  In  Cycle  2,  you  will  select  a  cycle  strategy  that  focuses  on  getting  sp(»sorship 
and  stakeholder  buy-in  to  the  transfer.  BT  modificaticMis  were  made  to  the 
transfer  plan,  then  you  may  need  to  select  a  new  transfer  strat^. 

Cycle  N  In  later  cycles,  you  will  select  a  strategy  for  the  current  cyde.  If  modificaticHis 

were  made  to  the  transfer  plan,  then  you  may  need  to  sdect  a  new  transfer 
strategy. 

2.  Select  the  Technology  You  need  to  select  a  technology  that  you  recom¬ 
mend  for  transfer.  You  will  need  to  document  why  you  selected  one  technolo¬ 
gy  over  the  others. 

Cycle  I  In  the  first  cycle,  you  need  to  evaluate  and  select  a  technology  from  the 
alternative  technologies  identified  in  the  Define/Update  Transfer  Strate¬ 
gies  activity,  lb  perform  the  evaluation  and  selection,  you  can  use  the  Com¬ 
parative  Evaluation  Method  (CEM)  (Software  Productivity  Consortium 
1991).  The  software  package.  Expert  Choice,  by  Decision  Support  Soft¬ 
ware,  Inc.,  (Forman  et  al.  1983)  provides  automated  support  for  CEM.  This 
task  summarizes  the  CEM;  you  should  refer  to  Software  Productivity 
Consortium  (1991)  for  a  full  description  of  the  method. 

CEM,  adapted  for  technology  transfer,  is  based  on  the  Analytic  Hierarchy 
Method  (Saaty  1980).  CEM  requires  you  to  establish  needs,  evaluate  the 
alternatives,  and  then  select  the  technology.  The  following  guidance 
summarizes  each  of  these  actions. 

•  Establish  Needs.  Perform  the  following  to  establish  the  needs  for  the 
technology: 

-  Using  the  transfer  objectives,  alternatives,  and  constraints;  the 
technology  requirements;  and  the  risk  analysis,  categorize  and 
analyze  the  functions  of  the  desired  technology  and  determine  a 
set  of  mandatory  and  desired  needs  for  the  technology.  These 
needs  should  include  technical  needs  (e.g.,  the  technology  needs  to 
have  a  response  time  not  greater  than  2  seconds),  cost  consider¬ 
ations  (e.g.,  you  have  limited  funds  for  integration),  and  other 
transfer  constraints  (e.g.,  you  need  to  show  progress  within  2 
months  or  risk  losing  sponsor  support). 
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-  Develop  a  decision  model  that  prioritizes  each  of  the  needs  and 
provides  a  weight  that  indicates  the  relative  measure  of  the  impor¬ 
tance  of  each  need.  That  is,  instead  of  just  indicating  that  A  is  bet¬ 
ter  than  B,  you  need  some  relative  measure  of  how  much  better  A 
is  than  B. 

Eviduate  Alternatives.  Perform  the  following  to  evaluate  the  alternative 
technologies: 

-  Based  on  the  alternative  technologies  identified  in  the  Define/ 
Update  Transfer  Strategies  activity,  eliminate  those  technologies 
that  do  not  meet  the  mandatory  needs. 

-  Develop  a  questionnaire  based  on  the  decision  model  and  the 
mandatory  and  desired  needs.  The  purpose  of  the  questionnaire 
is  to  determine  not  only  that  a  product  provides  the  mandatory 
needs,  but  to  determine  how  well  it  provides  them  compared  to  the 
other  products.  The  questionnaire  ensures  thorough  coverage  of 
each  product  against  the  identified  needs. 

The  questionnaire  should  include  a  cost  profile  (e.g.,  acquisition, 
training,  support,  and  integration  costs)  and  a  producer  profile 
(e.g.,  producer  stability,  experience,  and  available  support). 

-  Analyze  each  of  the  technologies  against  the  questionnaire.  The 
risk  analysis  you  did  for  each  technology  in  the  Analyze  and  Re¬ 
solve  Risks  activity  provides  some  of  the  information  to  perform 
this  analysis. 

If  the  technology  you  are  trying  to  transfer  has  an  impact  on  your 
organization’s  software  development  process,  you  should  refer  to  the 
Technology  Benefits  Model  User  Manual  (Software  Productivity 
Consortium  1993c)  and  accompanying  prototype  tool.  The  Tfechnology 
Benefits  Model  tool  is  a  spreadsheet  implementation  of  various  models 
for  estimating  the  effect  of  using  a  new  technology  on  the  cost  of 
software  development.  You  can  use  this  tool  to  estimate  the  benefits 
of  each  alternative  technology  on  your  organization’s  software 
development  process. 

Select  Technology.  You  compare  the  evaluations  done  of  each  technology 
and  select  the  technology  to  be  transferred.  You  can  use  the  Expert 
Choice  tool  to  help  you  in  this  activity.  You  should  perform  this  activity 
with  the  input  and  buy-in  from  all  stakeholders. 

If  you  cannot  narrow  your  recommendation  down  to  a  single  technology, 
then  try  one  or  more  of  the  following  approaches: 

-  Define  high-level  implementation  plans  for  each  technology.  These 
plans  will  focus  on  the  ease  or  difficulty  of  the  implementation. 
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potentialty  helping  you  identify  the  right  technology  (see  the  Define 
Implementation  Plan  activity  for  guidance  on  how  to  generate  an 
implementation  plan). 


-  Test  a  technology  on  a  small  pilot  project. 

-  Present  more  than  one  technology  recommendation  to  the 
stakeholders  and  have  them  make  the  final  selection  (see  the 
Commit  to  Strategy  activity). 

Cycle  2...N  You  will  perform  this  task  in  a  later  cycle  if  the  technolc^  selected  earlier 

is  not  transferring  well  and  all  stakeholders  agree  that  the  technology  selec¬ 
tion  needs  to  be  revisited.  In  this  case,  you  should  follow  the  guidance  given 
under  Cycle  1  for  this  task. 


Stop  Criteku 

You  are  done  with  this  activity  when  you  have: 

•  The  recommended  transfer  and/or  cycle  strategy,  plus  dociunentation 
explaining  why  this  strategy  is  reconunended  over  the  others 

•  The  technology  recommended  for  implementation,  plus  documentaticHi 
explaining  why  this  technology  is  recommended  over  the  others 
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43  COMMIT  TO  STRATEGY 


This  activity  begins  at  the  end  of  Step  2,  Analyze  Risks  and  Select  Strategy. 


Overview 

Your  objective  in  this  activity  is  to  get  all  stakeholders  to  commit  to  the 
strategy  for  the  transfer  and/or  the  (^cle  and,  when  appropriate,  the 
technology  selected  for  the  transfer.  A  k^  part  of  this  activity  is  for  the 
sponsors  to  publicize  the  recommendation  and  commitment  across  the 
organization. 

You  should  not  proceed  with  the  transfer  until  you  have  successfully 
completed  this  activity. 


Start  Criteria 


You  should  start  this  activity  when  you  have: 

•  A  recommended  strategy  for  the  transfer  and/or  the  cycle,  along  with 
documentation  explaining  why  the  strategy  is  reconunended 

•  When  appropriate,  a  recommended  technology,  along  with 
documentation  explaining  why  the  technology  is  reconunraded 


Tasks 


You  need  to  obtain  approval  from  the  stakeholders  on  the  selected  transfer 
and/or  cycle  strategy  and,  when  needed,  on  the  selected  technology. 

K  this  transfer  is  part  of  a  process  improvement  effort,  then  you  need  to 
get  review  and  app  oval  from  the  Process  Group.  Depending  on  your  par¬ 
ticular  situation,  the  Process  Group  will  either  be  the  sponsors  or  the 
champions  for  this  transfer. 

1.  Obtain  Review  and  Approval  FVom  Champions,  Change  Agents,  and 
End  Users.  You  should  seek  approval  first  from  all  stakeholders  other  than 
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the  sponsors.  The  sponsors  will  be  more  likely  to  approve  a  selection  when 
there  is  buy-in  from  all  the  other  players  involved  in  the  transfer.  Because 
the  champions  and  the  change  agents  helped  identify  the  selected  strate¬ 
gies,  then  the  focus  of  this  task  will  be  on  getting  review  and  approval  from 
the  end  users  and  any  other  champions  and  change  agents  that  did  not  par¬ 
ticipate  in  the  selection.  You  may  need  to  go  through  several  iterations  of 
the  review  process  before  they  will  approve  it. 


Cycle  I 

Cycle  2...N 


In  the  first  cycle,  you  will  get  approval  on  the  transfer  and  cycle  strategies 
and  the  selected  technology.  You  need  to  get  conunitment  from  the  change 
agents  and  champions  involved  in  developing  the  transfer  plan. 

In  future  cycles,  you  need  to  get  approval  on  the  cycle  strategy  and  on  any 
modifications  to  the  transfer  strategy  or  to  the  technology  selection.  You 
need  to  get  commitment  from  the  change  agents,  champions,  and  end  users 
identified  in  the  Build/Reinforce  Sponsorship  and  Foundation  activity. 

2.  Obtain  Commitment  From  Sponsors.  After  you  have  buy-in  from  all 
champions,  change  agents,  and  the  end  users,  you  need  to  present  your  rec¬ 
ommendations  for  the  strategy  and  technology  to  the  sponsors  for  their 
commitment.  Your  presentation  should  include: 


•  A  description  of  the  reconunendation(s) 

•  Your  rationale  for  the  recommendation(s) 

•  The  impact  of  the  recommendation(s)  on  the  organization,  especially 
the  impact  on  each  sponsor’s  group 

•  The  estimated  cost  and  time  frame  for  the  recommendation(s) 


Depending  on  your  situation,  you  may  decide  to  stagger  the  presentations, 
targeting  first  those  sponsors  who  are  more  supportive  in  order  to  build 
up  a  stronger  case  for  those  sponsors  who  are  less  supportive. 

You  may  have  several  iterations  in  your  presentation  to  management 
before  you  get  a  final  decision  to  go  ahead  with  the  implementation.  If  so, 
return  as  necessary  to  any  task  in  this  activity  or  in  the  Analyze  and  Resolve 
Risks  or  Select  Strategy  activities  to  get  the  decision  to  proceed. 

Cycle  1  In  the  first  cycle,  you  will  not  perform  this  task  since  you  do  not  yet  have 
a  sponsor. 

Cycle  2  In  Cycle  2,  you  need  to  get  a  commitment  on  the  selected  cycle  strategy 
and  on  any  modifications  to  the  transfer  strategy  or  technology  selection. 
You  will  seek  commitment  from  the  authorizing  and  reinforcing  sponsors 
identified  in  the  Build/Reinforce  Sponsorship  and  Foundation  activity. 
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Cycle  N  In  later  cycles,  you  will  get  a  commitment  on  the  cycle  strategy  and  any 
modifications  to  the  transfer  strategy  or  the  selected  technology.  You  wiU 
seek  commitment  firom  the  authorizing  and  reinforcing  sponsors  identified 
in  the  Build/Reinforce  Sponsorship  and  Foundation  activity. 


$ 


3.  Publicize  Commitment.  After  approving  the  recommendation,  the 
sponsors  need  to  publicize  their  support  and  commitment  throughout 
their  organization  to  keep  everybody  informed,  to  ensure  the  end  users  that 
the  transfer  is  important,  and  to  help  prepare  everybody  for  the  changes 
ahead,  lb  publicize  their  support  and  commitment  to  the  transfer,  the 
sponsors  may  send  a  memorandum  or  electronic  mail,  hold  an  organiza¬ 
tion-wide  meeting,  or  hold  a  series  of  briefings  across  the  organization. 


You  can  use  the  influence  strategy  developed  in  the  Build/Reinforce 
Sponsorship  and  Foundation  activity  in  planning  and  implementing  this 
task. 

Cycle  I  In  the  first  cycle,  you  will  not  perform  this  task  because  you  do  not  want 
to  publicize  any  strategies  or  technologies  until  you  have  commitment  from 
all  stakeholders. 


Cycle  2...N  In  later  cycles,  you  should  work  with  the  sponsors  to  publicize  the  decision 
and  their  support  and  commitment  to  the  transfer  to  help  prepare  everybody 
for  the  changes  ahead. 


Stop  Criteria 


You  are  done  with  this  activity  when: 

•  You  have  commitment  from  all  stakeholders  on  the  transfer  and/or 
cycle  strategy  and,  when  appropriate,  on  the  technology  selected  for 
transfer 

•  The  sponsors  have  publicized  their  commitment  to  the  organization 
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PLAN  TECHNOLOGY  IMPLEMENTATION 


Organizations  that  successful^  introduce  new  technology  concern  themselves  with  the  impUcatiais 
of  the  new  ^em  as  much  or  more  so  than  with  the  technology  itself. 


Section  Otyectives 

1.  Prowde  guidance  for 
planning  the 
implemaUation  for  this 
cycle 

2.  Provide  guidance  for 
getting  commitment  on 
the  plan 


Daryl  Conner,  Managing  at  the  Speed  of  Change 

Implementation  of  the  technology  will  be  helped  if  a  coherent,  informed, 
documented,  and  public  planning  activity  occurs.  Figure  S-1  shows  the  two 
activities  described  in  this  section. 


Figure  S-1.  Plan  Technology  Implementation  Activities 


You  will  perform  the  Define  Implementation  Plan  activi^  first,  followed 
by  the  Commit  to  Implementation  Plan  activity. 
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5.1  DEFINE  IMPLEMENTATION  PLAN 


Overview 


This  activity  begins  in  Step  3,  Plan  Ibchnology  Imi^mentaticm. 


Your  objective  in  this  activity  is  to  define  the  implementation  for  the 
current  cycle  and  document  it  in  an  implementatitm  plan.  The  plan  will 
be  based  on  the  cycle  objectives,  constraints,  and  strategy  defined  and 
approved  in  the  previous  steps  of  this  cycle. 

You  will  not  perform  this  activity  until  you  have  achieved  sponsorship, 
defined  and  received  approval  on  a  transfer  and  (tycle  strategy,  and 
selected  a  technology. 


Start  Crtteru 


You  should  start  this  activity  when  you  have: 

•  Sponsorship  and  stakeholder  buy-in  to  the  transfer 

•  An  approved  cycle  strategy,  objectives,  and  constraints 

•  A  technology  approved  for  implementation 

•  A  risk  management  plan  that  documents  the  risks  associated  with  the 
technology  and  the  selected  transfer  and  cycle  strategies 

•  An  understanding  of  the  process  and  computing  environment  to  be 
changed 

•  Previous  examples  of  implementation  plans,  if  available 


Tasks 


You  will  develop  a  plan  that  defines  the  implementation  for  the  tycle  and  then 
assess  the  risks  associated  with  the  plan.  The  implemoitatitm  plan  will  in¬ 
clude  success  criteria  for  the  implementation,  along  with  associated  data  col¬ 
lection  requirements:  implementation  tasks;  and  budget  and  staffing 
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1.  Identify  Success  Criteria  and  Associated  Data  Collection  Requirenients. 
Y(hi  need  to  define  the  success  criteria  for  the  cuirent  cycle  and  define  when 
in  the  cycle’s  implementation  you  will  assess  progress  against  these  success 
criteria.  You  need  to  predict  how  far  along  the  transfer  will  proceed  in  this 
qicle;  you  will  compare  this  prediction  to  tl^  actual  progress  made  in  the 
Review  Progress  activity.  You  will  also  use  your  predictitHis  vriien  you  seek 
sponsor  commitment  to  the  plan. 


Cycle  1,2  You  will  not  perform  this  task  in  Cycles  1  or  2. 


Cyie  N  The  following  list  contains  guidance  for  defining  the  success  criteria  and 
data  collection  requirements: 


•  Success  Criteria.  The  tide’s  success  criteria  will  be  the  measure  against 
which  you  will  determine  when  the  implementation  has  reached  such 
a  state  that  you  should  perform  a  full-scale  review  and  update  of  plans 
as  described  in  Step  5  (see  Section  7,  Determine  Where  lb  Go  Next; 
Review  and  Update  Transfer  Plan).  Your  success  criteria  must; 


-  Support  both  the  (^cle  and  transfer  objectives  and  strategies. 

-  Define  when  the  implementation  will  be  complete  for  this  cycle. 

-  Ensure  progress  against  the  overall  transfer  objectives  and  success 
criteria. 

-  Incorporate  criteria  by  which  your  stakeholders  will  measure  the 
success  of  the  transfer.  What  are  potential  or  actual  baseline 
measures  for  time,  productivity,  quality,  and  cost? 

-  Incorporate  criteria  that  measure  user  satisfaction  with  the 
technology  and  the  transfer.  For  example,  does  a  poll  of  the  users 
show  that  more  than  half  are  satisfied  with  the  technology?  Do  the 
users  feel  that  training  and  support  were  adequate? 

-  Incorporate  criteria  that  measure  the  degree  of  transfer.  For 
example,  you  may  want  to  include  a  success  criterion  that  requires 
that  a  core  feature  of  the  technology  be  used  because  that  feature 
was  key  to  that  technology’s  selection.  If  the  key  feature  is  never 
used,  then  you  need  to  understand  why  this  has  occurred  and 
address  it  in  future  cycles. 

To  define  success  criteria,  you  can  use  the  Goal-Question-Metric 

(GQM)  paradigm.  GQM  systematically  develops  and  specifies  quanti¬ 
tative  management  measurements  and  metrics  appropriate  for  an 

identified  need.  The  GQM  paradigm  is  summarized  in  the  following 
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list;  for  additional  detail,  see  Basil!  and  Weiss  (1984X  Gilb  (1988X  ^ 

Weiss  (1981). 

-  State  the  Goat  State  a  single  goal  of  importance  to  the  transfer.  For 
example,  a  goal  may  be  for  the  technology  to  increase  productivity 
by  25%. 

-  State  Ae  Question.  Decide  which  question(s)  you  need  to  ask  to 
determine  whether  the  goal  is  being  or  has  been  met  Continuing 
the  previous  example,  your  questions  may  include;  “How  long  (toes 
it  currently  take  ^e  organization  to  perform  this  task?”  “What 
parts  of  the  task  are  affected  by  the  new  technology?” 

-  Sl^lheAlieincs.  Select  the  metrics  you  need  to  c(^ect  to  answer  the 
questions.  Continuing  the  example,  your  metrics  may  include  staff 
m(Hiths  expended  cm  the  task.  Ihese  metrics  form  the  basis  for  the 
data  you  collect  during  the  implementation  to  determine  whether  the 
transfer,  as  defined  for  the  current  c^cle,  has  succeeded. 

•  Data  Collection  Kequirenunts.  You  need  to  define  requirements  for  how 

the  data  will  be  collected  during  the  implementation.  Your  data  cc^ecticm 

requirements  must* 

-  Be  tied  directly  to  this  cycle’s  success  criteria. 

-  Include  specifications  of  what  data  will  be  collected,  when  it  will 
be  collected,  who  will  collect  it,  and  from  ^om  the  data  will  be 
collected. 

Subjective  measures  will  be  the  easiest  to  expect  early  in  the  transfer; 
therefore,  early  in  the  transfer  you  should  cdlect  subjective  measures 
frequentfy  (e.g.,  every  2  months  for  the  first  12  months)  in  the  transfer 
and  then  taper  off  as  the  transfer  progresses.  Objective  measures  are 
better  collected  after  the  users  have  used  the  technology  for  a  while 
and  should  be  collected  after  the  technology  has  had  a  chance  to 
make  an  impact  (e.g.,  after  6  months).  However,  if  the  technology  is 
easily  measured  objective^  (e.g.,  a  tool)  then,  early  in  the  transfer  you 
should  measure  frequentfy  (e.g.,  every  2  months  for  the  first 
12  months)  in  the  transfer. 

-  Ensure  that  data  collected  includes  data  received  from  talking  to 
and  surveying  users  to  determine  their  level  of  satisfaction  with  the 
new  technology. 

-  Identify  the  specific  times  during  the  cycle’s  implementation 
period  (“snap  shots”)  when  implementation  should  be  assessed 
against  the  success  criteria. 
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2.  Define  Implementation  Tasks.  You  need  to  define  what  tasks  will  be 
performed  during  the  current  cycle’s  implementation. 

If  this  transfer  is  part  of  a  process  improvement  effort,  then  you  need  to 
work  with  the  Process  Group  to  make  sure  that  the  implementation  tasks 
you  define  are  consistent  with  the  overall  process  improvement  plan  as  well 
as  other  transfer  efforts.  For  example,  you  do  not  want  to  plan  on  using 
support  resources  that  are  already  heavily  burdened  by  parallel  improve¬ 
ment  and  transfer  efforts.  These  issues  should  have  been  identified  as  con¬ 
straints  and/or  risks  in  earlier  activities  in  the  current  cycle;  however,  they 
are  repeated  here  because  of  their  importance  to  the  process. 

General  planning-related  guidance  that  relates  to  each  implementation 
task  includes  the  following: 

•  Order  the  implementation  tasks,  including  task  interactions,  roles  and 
responsibilities,  schedules,  and  level  of  effort. 

•  Indicate  the  expected  results  and  deliverables  of  specific  tasks. 

When  scheduling  the  implementation  tasks,  you  need  to  be  aware  that  the 
schedule  will  be  influenced  by  your  available  resomces,  the  technology, 
and  the  end  users.  Specific  influences  in  each  of  these  areas  follow: 

•  Resource  Influences.  If  you  have  limited  resources  but  are  less 
constrained  on  schedule,  then  assign  less  staff  and  more  time  to  per¬ 
form  the  activities  (however,  be  aware  of  biases  resulting  from  a  single 
person  doing  aU  of  the  analyses  and  definition).  If  you  have  a  tight 
schedule  but  are  less  constrained  by  resources,  then  perform  activities 
concurrently  with  more  staff  on  each  activity  (however,  in  this  case,  be 
aware  of  integration  issues  across  the  activity  results).  If  you  are  lim¬ 
ited  on  time  and  resources  (and  cannot  change  the  situationX  the  best 
guidance  is  to  delay  the  transfer  until  your  situation  improves.  Figure 
5-2  depicts  these  ideas. 

•  Technology  Ii^Iuatces.  Ifechnologies  differ  in  their  complexity,  adaptabili^, 
compatibility  with  the  edsting  environment,  maturity,  and  scope  of  im¬ 
pact  on  your  organixation.  For  example,  some  technologies  may  involve 
no  more  than  a  plug-in  to  a  handful  of  workstations  (e.g.,  a  new  schedul¬ 
ing  tool)  while  other  technologies  may  demand  changes  in  the  skills  of 
all  employees  (e.g.,  switching  everybody  to  a  high-powered  workstation). 
You  need  to  factor  in  the  technology’s  characteristics  when  scheduling 
integration,  support,  and  training  tasks. 

•  End  User  Influences.  The  transfer  will  be  influenced  by  the  number  of 
staff  targeted  to  use  the  new  technology,  the  existing  skills  of  the  staff 
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Figure  S-2.  High  Risk  Areas  and  Order  of  Activities 


(e.g.,  how  much  training  will  be  needed?),  and  the  current  envinmment 
that  they  work  in  (e.g.,  will  the  end  users  also  need  training  in  the  new 
hardware  environment  required  by  the  technology?).  You  need  to  factor 
in  the  end  user  characteristics  i^en  scheduling  training  and  support 
tasks. 

You  will  not  perform  this  task  in  Cycles  1  or  2. 

You  need  to  define  implementation  tasks  that  address  integradon,  training, 
support,  and  organization  change  and  logistics  requirements.  The  following 
lists  provides  guidance  for  each  of  these  tasks. 

•  Integration  Tiisk.  You  need  to  integrate  the  new  technology  into  the 
existing  environment  This  may  include: 

-  Interfacing  the  technology  to  existing  hardware  and  software, 
including  identifying  ai^  new  hardware  or  software  that  needs  to  be 
acquired  for  the  integration 

-  Modifying  or  creating  policies  and  procedures  to  maximize 
integration  into  the  system 

-  Identifying  and  developing  any  new  standards  (e.g.,  conventions, 
formats)  that  need  to  be  put  in  place  to  support  the  technology 

As  an  aid,  your  organization  might  have  in  place  an  approach,  or  plan, 
on  integrating  computer-based  tools,  methods,  and  technologies  into  the 
environment  that  you  can  use  in  the  implementation. 

Hiis  task  discusses  integration  issues  for  product  technologies  (e.g.,  tools 
or  methods).  Thmsferring  process  technologies  requires  a  major  integra¬ 
tion  effort  within  the  organization’s  culture,  practices,  and  environment 
Refer  to  Managing  Process  Improvement:  A  Guidebook  for  Iirgiemendr^ 
Changje  (Software  Productivity  Consortium  1993b)  for  guidance  on  how 
to  integrate  a  new  process  into  your  organization. 
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TYaining  Task.  You  need  to  define  any  training  tasks  to  be  performed 
in  this  cycle.  Specifically  you  need  to; 

~  Identify  the  personnel  to  be  trained,  required  training  types  (e.g., 
management  overview,  classroom),  and  the  schedule. 

-  Identify  the  source  of  the  training,  including  any  needed  training 
tools,  and  the  training  providers.  If  the  techndogy  is  available  from 
a  producer  and  you  have  an  internal  training  group,  then  you  need 
to  understand  the  tradeo&  between  using  one  group  or  another. 
If  a  small  number  of  staff  will  be  using  the  new  technology,  then 
producer-provided  training  is  probabfy  the  most  cost-effective.  If 
a  large  number  of  staff  will  be  using  the  new  technology,  then  it 
might  be  cost-effective  to  use  your  organization’s  internal  training 
functions,  possibly  in  cooperation  with  the  producer,  to  provide 
the  training.  The  cut  off  point  for  when  it  is  cost-effective  to  use 
internal  versus  producer  resource  for  training  should  be  based  on 
cost  estimates  for  course  development  and  delivery  and  on  cost 
estimates  for  producer-supplied  training. 

If  the  technology  is  not  available  from  a  producer,  then  you  need 
to  build  adequate  time  into  the  schedule  to  develop  your  own  train¬ 
ing.  A  general  rule  of  thumb  in  industry  is  that  it  takes  at  least  40 
hours  of  course  development  time  for  each  1  hour  of  classroom 
time. 

-  Identify  how  the  training  will  be  evaluated  (e.g.,  did  the  users 
acquire  the  needed  skills?) 

-  Closely  coordinate  the  timing  between  training  and  the  other  tasks. 
If  the  technology  is  bolted  in  and  turned  on  and  nobody  knows  how 
to  operate  it,  the  benefits  will  be  negligible.  In  addition,  if  the  staff 
is  trained  4  months  before  they  use  the  technology,  then  the 
training  benefits  are  greatly  reduced. 

As  an  aid,  if  you  or  your  organization  has  modeled  the  process  for  the 
area  being  modified  by  the  technology,  then  you  can  use  that  model 
in  your  training. 

Support  Task.  You  need  to  define  who  will  be  providing  support  services 
in  this  cycle.  These  services  may  include  consulting  and  hotline 
support.  Specifically,  you  need  to: 

-  Define  what  support  services  will  be  provided,  including 
procedures  for  how  to  handle  support  calls  and  how  the  support 
services  will  be  staffed. 


Identify  the  source  of  the  support,  including  any  needed  support 
tools,  and  the  support  providers.  If  support  is  available  from  a 
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producer  and  you  have  an  internal  support  group,  then  you  need 
to  understand  the  tradeofiEs  between  using  one  group  or  another. 
If  a  small  number  of  staff  will  be  using  the  new  technology,  then 
producer-provided  support  is  probably  the  most  cost-effective.  If 
a  large  number  of  staff  will  be  using  the  new  technology,  then  it 
might  be  cost-effective  to  use  your  organization’s  internal  support 
functions,  possibfy  in  cooperation  with  the  producer,  to  provide 
the  support.  The  cut-off  point  for  when  it  is  cost-effective  to  use 
internal  versus  producer  resources  for  support  should  be  based  on 
cost  estimates  for  training  and  funding  internal  support  personnel 
and  on  cost  estimates  for  producer-supplied  support. 

-  If  using  a  producer  for  any  or  all  of  the  support,  make  sure  they 
agree  to  provide  these  services.  If  not  using  a  producer,  make  sure 
that  your  internal  support  personnel  are  available  to  provide  the 
support  and  agree  to  their  role  in  the  transfer. 

The  support  techniques  you  can  use  include: 

-  Access  to  technology  experts,  preferably  permanently  or 
temporarily  transferred  to  the  group. 

-  Consulting,  especially  access  to  one-on-one,  hand-bolding  by  an 
expert  for  the  first  1  to  3  hours  using  the  tool.  Have  the  expert  come 
back  at  least  once  every  month  throughout  the  transfer  to  help 
solve  problems  and  address  concerns. 

-  Hotline  support,  especially  toll-free,  unlimited  support  for  the 
first,  critical  period  of  the  transfer. 

-  A  frequently  asked  questions  list  that  documents  common  end 
user  problems  and  solutions  that  you  can  hand  out  to  all  users. 

During  the  initial  transfer  period,  plan  to  have  a  high  demand  for 
support,  including  installation,  usage  questions,  and  solutions  to  bug 
reports.  Demand  should  taper  off  as  experience  is  gained,  but  new  us¬ 
ers  will  require  a  high  level  of  support,  and  existing  users  will  still 
require  support  from  time  to  time. 

•  Organization  Change  Task.  In  the  current  cycle,  you  need  to  define  any 
changes  needed  in  the  organization.  Specifically,  you  need  to  identify 
the  structural  changes  in  the  organization  necessitated  by  the  chosen 
technology,  including  reporting  relationships,  group  composition, 
titles,  redesign  of  positions,  compensation  plans,  and  procedures.  For 
example,  some  technologies  may  demand  new  job  responsibilities  and 
job  descriptions  while  other  technologies  may  demand  different  com¬ 
munication  patterns  across  functions.  You  may  want  to  simulate  the 
changes  through  models,  games,  role  playing,  or  other  approaches  to 
help  identify  potential  problems  before  they  are  instituted. 
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•  Logistics  Tadu  You  need  to  address  the  It^tical  aspects  of  transfer. 
These  include  issues  of  capital  acquisition,  movement  of  offices  and 
people,  organizational  infrastructure  changes  (e.g.,  running  cable),  and 
other  technology  specific  issues. 

3.  Define  Budget  and  Staffing.  You  need  to  define  the  expected  budget 
and  staffing  requirements  for  this  cycle.  If  part  of  a  process  improvement 
effort,  the  budget  and  staffing  for  the  transfer  need  to  be  consistent  with 
the  budget  and  staffing  defined  for  the  improvement  effort. 

You  will  not  perform  this  task  in  Cycles  1  or  2. 

In  later  cycles,  you  need  to; 

•  Identify  needed  internal  and  external  resources,  including  trainers, 
system  administrators  to  perform  hardware  or  software  integration, 
and  consultants  to  do  hand-holding  with  the  new  users.  These  require¬ 
ments  should  be  consistent  with  the  implementation  tasks  you  have 
described  in  the  implementation  plan. 

•  Identify  the  expected  costs  for  this  cycle.  Understand  the  costs  for  any 
acquisition  of  hardware  and  software,  training  (both  development  and 
delivery),  support  requirements,  integration  time  and  costs,  and  initial 
productivity  loss  due  to  the  learning  curve.  These  costs  should  be  con¬ 
sistent  with  the  implementation  tasks  you  identified  earlier  and  should 
be  within  the  budget  defined  for  the  cycle. 

•  Allocate  time  and  resource  contingencies  to  handle  such  problems  as 
emerging  opposition,  fading  management  support,  interference  of 
other  seemingly  independent  changes,  and  system  troubles. 

4.  Identify  and  Analyze  Risks  Associated  With  Implementation  Plan.  You 
need  to  identify  any  ffsls  associated  with  your  implementation  plan  and 
analyze  and  avert  those  risks.  You  should  document  the  results  of  this  task 
in  your  risk  management  plan.  This  task  lists  some  risks  common  in  an 
implementation  plan;  you  should  refer  to  the  Analyze  and  Resolve  Risks 
activity  for  guidance  on  how  to  identify,  analyze,  and  avert  risks. 

You  will  not  perform  this  task  in  Cycles  1  and  2. 

You  need  to  look  at  the  implementation  plan  and  identify  any  risks 
inherent  in  the  plan.  Risks  that  you  should  look  for  include: 

•  Overly  ambitious  success  criteria,  schedule,  staffing,  or  budget. 

•  Staffing  assignments  that  require  staff  who  do  not  like  each  other  to 
work  together. 


^  Sponsor 


Change  tZ/i  Champion 

Agent 


End  User 


5-9 


S.  Focus  the  IVansfer  Plan  Ifechnology  Implementation 

H 

sii' 

•  Producer  inability  to  meet  the  demands  of  the  cycle  (e.g..  there  are  a 
lot  of  new  users  for  the  cycle  and  the  producer  cannot  meet  the  support 
demands). 


•  Any  stakeholders  to  be  involved  in  the  ^rcle  have  not  bought  into  the 
transfer  yet. 

•  New  users  do  not  have  adequate  prerequisites  or  experience  to  either 
use  the  tool  or  be  trained. 

•  Inadequate  resource  contingencies  to  address  new  risks  as  they  occur. 


Stop  Criteru 


You  should  stop  this  activity  when  you  have  an  implementation  plan  that 
details  what  needs  to  be  done  to  progress  the  transfer  during  this  cycle. 
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This  activity  begins  at  the  end  of  Step  3,  Plan  Ikchnology  Implementati<Ni. 


Overview 

Your  objective  in  this  activity  is  to  get  all  stakeholders  to  commit  to  the 
implementation  plan  for  this  cycle.  A  part  of  this  activity  is  that  the 
sponsors  publicize  the  commitment  across  the  organization. 

You  will  not  perform  this  activity  until  you  have  achieved  sponsorship  and 
defined  and  received  approval  on  the  transfer  and  cycle  strategies. 

You  should  not  proceed  with  the  transfer  until  you  have  successfully 
completed  this  activity. 


Start  Criteria 


You  should  start  this  activity  when  you  have: 

•  An  approved  qrcle  strategy,  objectives,  and  constraints 

•  A  detailed  implementation  plan  for  the  cycle 


Tasks 


& 


You  need  to  obtain  approval  from  the  stakeholders  on  the  implementation 
plan. 

If  this  transfer  is  part  of  a  process  improvement  effort,  then  you  need  to 
get  review  and  approval  from  the  Process  Group.  Depending  on  your  par¬ 
ticular  situation,  the  Process  Group  will  either  be  the  sponsors  or  the 
champions  for  this  transfer. 

1.  Obtain  Review  and  Approval  Firom  Champions,  Change  Agents,  and 
End  Users.  You  should  seek  approval  first  from  all  stakeholders  other  than 
the  sponsors.  The  sponsors  not  approve  the  plan  imtil  there  is  buy-in 
from  all  the  other  players  involved  in  the  transfer. 
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Cycle  You  will  not  perform  this  task  in  Cycles  1  and  2. 


Cycle  N  You  need  to  get  the  identified  champions,  change  agents,  and  end 
users  to  review  and  approve  the  plan.  You  may  need  to  go  through  several 
iterations  in  the  review  process  before  th^  will  approve  it. 


Cycle 


2.  Obtain  Commitment  Firom  Sponsors.  You  need  to  get  a  commitment 
from  the  identified  sponsors  on  the  implementation  plaa 

You  will  not  perform  this  task  in  Cycles  1  and  2. 


Cycle  N  After  you  have  approval  firom  the  champions,  change  agents,  and  end 
users,  you  need  to  present  your  plan  to  the  identified  sponsors  for  their 
commitment.  Your  presentation  should  include: 


•  A  description  of  the  plan 

•  How  the  plan  supports  the  cycle  objectives  and  your  predictions  on  the 
progress  that  will  be  made  against  the  overall  transfer  objectives 

•  How  this  plan  will  affect  each  part  of  the  organization  for  this  cycle, 
especially  the  groups  related  to  the  sponsors  you  are  briefing 

•  The  estimated  cost  and  time  frame  for  the  implementation  of  this  plan 

Depending  on  your  situation,  you  may  decide  to  stagger  the  presentations, 
targeting  first  those  sponsors  who  are  more  supportive  in  order  to  build 
up  a  stronger  case  for  those  sponsors  who  are  less  supportive. 

You  may  have  several  iterations  in  your  presentation  to  management  before 
you  get  a  final  decision  to  go  ahead  with  the  implementadoa  If  so,  return  as 
necessary  to  any  task  in  this  acdvi^  or  in  the  Define  Implementation  Plan 
activity  to  get  the  decision  to  proceed. 

3.  Publicize  Commitment.  After  approving  the  implementation  plan,  the 
sponsors  need  to  publicize  their  support  and  commitment  throughout 
their  organization  to  keep  everybody  informed,  to  ensiure  the  end  users  that 
the  transfer  is  important,  and  to  help  prepare  everybody  for  the  changes 
ahead.  To  publicize  approval,  the  sponsors  may  send  a  memorandum  or 
electronic  mail,  hold  an  organization-wide  meeting,  or  hold  a  series  of 
briefings  across  the  organization. 

You  can  use  the  influence  strategy  developed  in  the  Build/Reinforce 
Sponsorship  and  Foundation  activi^  in  plarming  and  implementing  this  task. 

Cycle  1^  You  will  not  perform  this  task  in  Cycles  1  and  2. 
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Ode  N  You  should  work  with  the  sptmsors  to  publids  the  decision  and  their 
support  and  commitment  to  the  transfer. 


Stop  Criteua 


You  are  done  with  the  activity  when: 

•  You  have  commitment  from  the  stakeholders  on  the  implementation 
plan 

•  The  sponsors  have  publicized  their  commitment  to  the  organization 


6.  GETTING  rr  DONE: 
IMPLEMENT  TECHNOLOGY 


There  has  been  an  enormous  amount  of  pain  and  trauma.  And  the  culture’s  not  comidetelly  dianged  yet. 

J.  Phillq)  Sanq)er,  \%e  Chairman,  Kodak 

Getting  the  rad  users  to  use  the  new  technology  is  the  hardest  part  of  the 
entire  process.  People  naturalfy  resist  new  things  and  without  constant  mo¬ 
tivation  and  support  will  not  use  the  new  technolt^.  If  you  do  not  pay  ade¬ 
quate  attention  to  this  activity,  despite  all  of  the  planning  you  have 
performed,  the  transfer  will  fail  Figure  6-1  shows  the  three  activities 
described  in  this  section. 


Figure  6-1.  Implement  Ihchnotogy  Activities 


You  will  perform  the  Implement  and  Manage  and  Monitor  activities  in 
parallel  and  the  Review  '^hnology  Implementation  activity  at  the  rad. 


Section  MjecUve 

far 

impkmentingthe 
technology  into  the 
orgamzation 
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6.  Getting  it  Done;  Intplemenl  lechnology 


6.1  IMPLEMENT 


This  activity  begins  in  Step  4,  Implement  Ihchnology. 


Your  objective  in  this  activity  is  to  cany  out  the  implementation  plan  for 
this  cycle.  You  should  do  this  with  the  same  urgency  as  you  would  a  con¬ 
tract  project  for  an  external  client,  including  following  standard  scheduling 
and  monitoring  procedures.  However,  in  the  process  of  carrying  out  the 
plan,  you  will  run  into  users  that  are  not  willing  or  able  to  use  the  technolo¬ 
gy,  sponsors  that  have  wavering  support  for  the  transfer,  change  agents 
that  get  distracted  by  other  work  demands,  and  champions  that  do  not 
have  the  energy  to  continue  publicly  supporting  the  transfer. 

lb  alleviate  some  of  these  problems,  you  need  to  first  be  aware  that  these 
problems  will  occur.  By  being  aware  of  this,  you  may  be  able  to  prevent 
them  firom  occurring,  or  at  least  reduce  their  severity,  by  maintaining  com¬ 
munication  with  the  spcmsors,  keeping  the  champions  motivated,  and 
supporting  the  end  users  so  that  their  problems  are  resolved  quickty. 

You  will  not  perform  this  activity  until  you  have  achieved  sponsorship  and 
defined  and  received  approval  on  the  implementation  plan. 


Start  Criteiua 


You  should  start  this  activity  when  you  have: 

•  An  approved,  detailed  implementation  plan 

•  Resources  to  perform  the  implementation 


Tasks 


The  primary  task  in  this  activity  is  transferring  the  technology  as  specified 
in  the  implementation  plan  for  this  cycle.  The  other  tasks  are  listed  here 
as  separate  tasks  to  emphasize  their  kty  role  in  the  success  of  the  transfer: 
reinforcing  sponsorship,  addressing  resistance  to  change,  and  supporting 
the  end  users. 
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1.  Carry  Out  Imirieiiientation  Plan.  You  will  cany  out  the  actions  specified 
in  the  implementation  plan. 


Clyde  1,2 


You  will  not  perform  this  task  in  Cycles  1  and  2. 


Cycle  N  Implement  the  technology  as  specified  in  the  implementation  plan  for  this 
cycle.  This  may  include  initiating  pilot  projects,  conducting  the  training, 
starting  up  support  mechanisms,  and  carrying  out  all  other  tasks  in  the 
implementation  plan. 


T)  aid  the  implementation,  use  the  help  of  local  experts  in  the  use  of  the 
technology.  Ihese  people  can  be  invaluable  in  helping  new  users  learn  and 
become  comfortable  with  the  technology.  In  addition,  these  peq)le  can 
become  local  champions  for  the  technology. 

2.  Reinforce  Sponsorship.  Unless  you  maintain  communication  and  show 
ongoing  progress  to  your  sponsors,  you  risk  losing  their  support  and  their 
sponsorship  for  the  implementation  and  the  transfer. 


Cycle  1,2  You  will  not  perform  this  task  in  Qcles  1  and  2. 

Cycle  N  Tb  reinforce  sponsorship,  you  need  to  periodically  update  your  sponsors 

on  the  progress  of  the  implementation,  including  problems  that  you 
encountered  and  resolved  and  progress  against  the  overall  transfer. 


3.  Address  Resistance  to  Change.  Despite  the  fact  that  you  have  sought 
commitment  and  approval  throughout  the  transfer  process,  you  will  still 
encounter  management  and  staff  who  resist  the  change  throughout  the 
implementation. 


Resistance  is  a  natural  response  to  changes  that  cause  major  disruptions 
or  inconsistencies  to  the  status  quo.  The  more  dramatic  the  change,  the 
greater  the  resistance.  You  can  increase  your  effectiveness  in  implementing 
the  technology  by  understanding  and  respecting  this  natural  reaction. 


People  express  their  resistance  differently.  Covert  resistance,  the  harder 
to  manage,  occurs  when  people  disagree  with  the  change,  but  do  not  share 
their  concerns.  Instead,  they  may  choose  to  undermine  or  sabotage  the 
change.  Overt  resistance  is  much  easier  to  manage  because  you  can  direct¬ 
ly  address  their  issues  since  you  know  about  them.  Therefore,  you  should 
not  try  to  stifle  people’s  resistance  to  the  change;  rather  you  should  try  to 
bring  their  resistance  in  the  open  and  address  it  publicly.  If  one  stakehold¬ 
er  has  an  issue  with  the  transfer  or  technology,  you  can  bet  that  others  have 
the  same  issue;  if  you  address  the  issue  publicly,  then  you  address  it  for 
people  that  have  not  voiced  or  have  not  yet  run  into  the  issue.  In  fact,  if 
you  encourage  people  to  question  the  transfer  and  the  technology,  then  you 
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6.  Getting  il  Done:  Implement  Itchnology 


will  build  up  trust  and  support  because  of  your  openness  and  your  belief 
that  the  opinions  of  others  are  important. 

Pec^le  resist  change  even  when  it  is  perceived  as  positive.  The  positive 
reaction  pattern  to  change  is  depicted  in  Hgure  6-2  The  toms  used  to 
describe  these  stages  are  found  in  O.D.  Resources  (1989)  and  are  as  fdlows: 

•  Stage  I,  Uninformed  CerUunty.  In  this  stage,  a  person  is  confident  that 
the  change  is  entirely  for  the  better  and  has  Ugh  expectations  of  the 
results. 


•  Stage  2,  Informed  Doubt  In  this  stage,  a  person  begins  to  realize  that 
expectations  were  set  too  high.  Resistance  will  most  likely  surface 
during  this  stage  and  can  be  either  covert  or  overt. 

•  Stage  3,  Realistic  Concern.  In  this  stage,  a  person  begins  to  reconcile 
expectations  with  reality  and  to  think  positively  about  the  change. 

•  Stage  4,  Itformed  Certainty.  In  the  last  stage,  people  are  once  again 
confident  of  success  but  only  because  they  have  a  better  understanding 
of  what  will  and  will  not  change. 


Figure  6-Z  Positive  Response  to  Change 

By  being  aware  of  the  way  people  will  respond  to  change,  you  can  be 
proactive  in  helping  them  through  the  stages.  Guidance  for  how  to  do  this 
is  given  later  in  this  task. 

Cycle  1,2  You  will  not  perform  this  task  in  Cycles  1  and  2. 
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Cycle  N  Sponsors,  end  users,  and  even  champions  and  change  agents  will  all  resist 
the  change  at  one  time  or  another  throughout  the  process.  By  being  aware 
of  this,  you  can  be  proactive  in  reducing  the  resistance  and  helping  them 


_ 6.  Getting  it  Done:  Implement  Tfcchnotogy 

through  the  positive  response  to  change  depicted  in  Figure  6-2.  Ikble  6-1 
lists  several  reasons  why  each  stakeholder  group  may  resist  the  change 
along  with  some  strategies  you  can  adopt  to  reduce  this  resistance.  Several 
of  these  strategies  are  described  in  other  activities  in  this  guidebook.  They 
are  repeated  here  for  emphasis. 

l^le  6-1.  R^istance  to  Change  Refuses  and  Mitigation  Strategies 


Resistance  to  Change 
Responses 

Mitigation  Strategies 

If  end  users: 

Then  you  can: 

•  Refuse  to  use  the  new 
technology  because  of  dislike 
for  the  te^ology  or  for  the 
transfer 

•  Involve  end  users  in  the  planning  and 
decision-making  activities.  Be  honest  but 
upbeat  about  the  transfer  and  the  tech¬ 
nology.  Use  a  reward/recognition  ^em 
for  particq^is*  Provide  support. 

•  Quietly  subvert  the  transfer 
to  their  peers 

•  Encourage  the  end  users  to  express  their 
complaints  and  problems  publicly.  Con¬ 
tinuously  check  with  the  end  users  to  see 
how  things  are  going. 

•  Publicly  complain  about  the 
technology  and  the  transfer 

•  Encourage  continued  discussion  and 
address  their  concerns  as  best  you  can. 

If  change  agents  or  champions; 

Then  you  can; 

•  Lose  some  of  their 
enthusiasm  for  the  transfer 
as  the  transfer  progresses 

•  Hold  meetings  throughout  the  transfer 
to  keep  spirits  up.  Use  a  rewards  and  in¬ 
centive  program  to  maintain  enthusiasm. 

If  sponsors: 

Then  you  can: 

•  Want  to  discontinue  support 
of  the  transfer  due  to  loss  dT 
political  power 

•  Involve  the  sponsors  in  every  decision 
and  review.  Make  sure  th^  feel  a  part  of 
the  transfer.  Address  their  concerns. 

Example  6-1  describes  a  case  where  resistance  was  met  because  of  lack  of 
customer  and  management  buy-in  to  the  technology  and  how  the 
resistance  was  successful  in  .shopping  the  transfer. 


4.  Support  the  E^d  Users.  Once  end  users  have  a  new  technology  in  hand, 
th^  must  have  adequate  support  while  installing  and  using  the  technology. 
If  th^  do  not  get  adequate  support,  the  probability  of  full  acceptance  and 
use  of  the  technology  will  decrease  rapidly. 


Qck  1^  You  will  not  perform  this  task  in  Cycles  1  and  2. 
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6.  Getting  it  Done:  Implement  Technology 


Matchless  Computing,  Ina,  is  a  highly  regarded  defense  supplier  with  a  large  backlog 
of  contracts  for  Navy  information  systems.  Matchless  prides  itself  on  the  cohesiverKSS 
of  its  management  team.  (Ed  Froth,  the  CTO,  routinely  takes  other  members  of  the 
executive  group  on  golf  outings.)  The  firm  is  also  known  for  promoting 
innovativeness  among  ”the  troops.” 

Linda  Harris,  manager  of  Computer  Systems  for  Matchless,  has  taken  advantage  of 
this  support  for  innovation  in  the  past  and  sees  another  change  to  move  her 
organization  ahead  technically.  Currently,  most  of  Matchless’  plications  use  the 
System  402  database  product  from  Computer  Architects  of  Central  America 
(CACA).  She  knows  this  system  is  outdated;  the  new  DELPHI  database  system  offers 
more  features  at  a  lower  cost  In  her  opinion,  this  system  is  destined  to  become  the 
de  focto  industry  standard. 

But  how  can  she  deal  with  Matchless’  large  investment  in  leg»y  systems?  In  her 
search  for  a  solution,  Linda  calls  a  staff  meeting  to  discuss  alternatives.  At  the 
meeting,  her  Advanced  Technolr^  Group  assures  her  that  they  can  readily  devek^ 
a  translator  to  convert  the  existing  plications.  After  some  discussion,  Linda 
commissions  the  group  to  develop  the  system,  and  within  a  few  weeks  they  have 
achieved  a  98  to  99%  translation  automatically.  The  effort  is  deemed  a  technical 
success,  and  Matchless  is  poised  to  convert  from  System  402  to  the  DELPHI  system. 

John  Eyore,  the  accounting  department  manager  who  is  responsible  for  many  of  the 
System  402  plications  the  translator  would  change,  was  not  informed  of  Linda’s 
work,  and  resists  the  transfer.  Changing  the  database  system  will  require  some 
changes  in  the  way  his  department  operates.  John  is  also  concerned  it  could 
eventually  reduce  his  staffing  level,  in  effect  reducing  his  status  within  the 
organization.  As  a  result,  he  simply  refuses  to  adopt  Linda’s  solution,  putting  her  work 
in  limbo.  The  CTO  is  called  in  as  a  mediator.  The  weekend  before  the  CTO  is  to 
resolve  the  conflict,  he  is  seen  playing  golf  with  John  at  John’s  country  club.  Later 
that  week,  the  CTO  issues  a  memo  providing  John’s  department  with  a  waiver  from 
this  conversion  requirement 


Example  6-1  A  Case  of  Not  Getting  User  and  Management  Buy-In 

Cycle  N  Provide  support  as  defined  in  the  implementation  plan  for  this  cycle.  You 
may  need  to  provide  support  dynamically  if  you  are  running  into 
unexpected  support  problems. 

One  of  the  most  effective  ways  to  get  users  to  use  a  new  technology  is  to 
have  an  expert  work  with  them  as  they  use  it  the  first  time.  This  way,  ques¬ 
tions  can  be  answered  immediately  and  the  user  and  expert  can  develop 
a  rapport  which  will  increase  the  user’s  comfort  level. 


Stop  Crttema 


You  will  stop  this  activity  when  you  have  completed  the  implementation 
as  defined  in  the  implementation  plan  for  this  cycle. 
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6.2  MANAGE  AND  MONITOR 


This  activity  begins  in  Step  4,  Implement  'Kchnology. 


Overview 

Your  objectives  in  this  activity  are  to  manage  and  ccdlect  data  on  the 
implementation.  You  should  p^orm  this  activi^  in  the  same  manner  as  a 
contract  project  for  an  esctemal  client  In  fact,  you  should  adq>t  analogous 
processes  (i.e.,  schedule  monitoring  and  status  meetings  and  rqmrts). 

You  will  not  perform  this  activity  until  you  have  achieved  sponsorship  and 
defined  and  received  approval  on  the  implementation  plan. 


Start  Crtteru 

You  should  start  this  activi^  when  you  have: 

•  An  approved,  detailed  implementation  plan 

•  Resources  to  manage  and  monitor  the  implementation 

•  A  risk  management  plan  describing  potential  risks  for  the  cycle 


Tasks 

In  this  activity  you  will  manage  the  implementation,  gather  data  on  the 
implementation  as  it  progresses,  and  stay  on  top  of  implementation  risks. 

1.  Manage  Implementation.  It  is  important  that  the  implementation  show 
visible  progress  against  the  objectives  of  the  cycle  and  of  the  transfer,  lb 
do  this,  you  need  to  manage  the  implementation  so  that  you  will  have  in¬ 
sight  into  how  the  transfer  is  proceeding  and  can  show  visible  progress  to 
your  sponsors  and  other  stakeholders. 

Cycle  1,2  You  will  not  perform  this  task  in  Cycles  1  and  2. 

Cycle  N  The  implementation  needs  to  be  managed  just  as  any  contract  project 
would  be  managed.  Specifically,  you  will; 
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•  'fiack  progress  of  the  implementation  against  the  schedule  defined  in 
the  implementation  plan. 

•  Urack  progress  against  your  assigned  budget. 

•  Publicize  progress  of  the  implonentaticm  periodically  to  your 
management,  (^er  sponsors,  users,  and  other  groups  within  the 
organizatioa 

•  Begin  the  implementation  with  a  kickoff  meeting  and  invite  the 
champions,  the  change  agents,  and  a  representative  of  senior  manage¬ 
ment  (his/her  role  is  to  present  management  commitment  and  expecta¬ 
tions).  Devote  the  meeting  to  reviewing  each  implementation  task,  re¬ 
viewing  the  transfer  and  cycle  schedules,  confirming  resource  and 
people  availability,  and  building  enthusiasm  for  the  transfer.  The 
meeting  should  cl(»e  with  an  agreement  on  when  the  implementation 
tasks  will  begin  and  when  the  next  meeting  will  be  held. 

•  Hold  regular  meetings  throughout  the  implementation  to  highlight 
issues  and  problems  on  the  part  of  the  change  agents  (which  may  have 
interdependencies  across  tasks),  maintain  morale,  and  provide  a 
context  for  bargaining  over  the  implementation  plan  and  schedule. 

•  Maintain  communication  between  all  of  the  stakeholders  on  tbe  status 
of  the  transfer.  This  will  help  continue  momentum  and  buy-in  to  the 
transfer. 

•  Work  with  the  producer  to  ensure  that  any  support,  resolution  of  bug 
reports,  and  training  are  provided  and  maintained. 

2.  Gather  Implementation  Data.  You  need  to  gather  data  on  the 
implementation  as  it  progresses.  Requirements  for  what  data  to  collect  and 
when  to  collect  it  are  outlined  in  the  implementation  plan.  This  data  will 
be  used  in  the  next  task  to  determine  progress  against  the  implementation 
plan  and  in  the  Review  Progress  activity  to  review  the  implementation 
against  the  transfer  objectives. 

You  will  not  perform  this  task  in  Cycles  1  and  2. 

Assess  information  to  ensure  that  the  transfer  is  proceeding  according  to 
plan.  Specifically,  you  will: 

•  Ensure  that  you  are  routinely  receiving  any  progress  reports  of  transfer 
tasks. 

•  Gather  information  c%ectly  from  the  transfer  sites  because  the 
progress  reports  might  not  include  seemingly  minor  details. 


Change 
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Cycle  1,2 
Cycle  N 


You  should  make  sure  that  you  are  gathering  the  foUovdng  data: 

•  User  Satitfactum  Data.  You  need  to  question  the  end  users  and  ask 
about  their  level  of  satisfaction  >vith  the  technology.  Do  they  feel  that 
they  were  adequately  trained  to  use  the  technology?  Were  their  prob¬ 
lems  and  questions  resolved  in  a  timely  manner?  Did  they  run  into  any 
integration  problems?  Do  they  like  the  new  technology  and  is  it  helping 
them  in  their  job?  If  your  end  users  are  not  happy  with  the  technology, 
then  the  transfer  is  running  a  high  risk  of  failure  and  you  need  to  devote 
your  efforts  to  solving  their  problems. 

•  Technology  Effectaenas  Data.  You  need  to  collect  data  on  the  use  of  the 
technology  itself,  including  whether  the  end  users  are  using  the  tech¬ 
nology  correctly,  are  using  it  in  ways  not  originally  intended,  or  are 
using  it  at  all. 

•  Schedule  Data.  You  need  to  track  how  long  the  implementation  is 
taking,  including  training,  integration,  and  learning  curve  time. 

•  Budget  Data.  You  need  to  track  the  staff  hours  logged  against  the 
implementation,  including  training  hours,  support  hours,  and  hours 
spent  documenting  the  technology  and  the  transfer  process.  You  also 
need  to  track  other  costs  of  the  implementation,  including  acquisititm 
and  support  costs. 

3.  Determine  Progress  of  Implementation  Against  the  Plan.  You  will  take 
the  data  collected  in  the  previous  task  and  compare  it  to  the  success 
criteria  defined  in  the  implementation  plan. 

You  will  not  perform  this  task  in  Cycles  1  and  2. 

Compare  the  information  you  gathered  against  the  success  criteria  to 
determine  whether  you  are  progressing  as  e}q)ected.  If  the  implementation 
achieves  success  criteria,  you  need  to  determine  whether  to  continue  with 
the  implementation  or  start  a  formal  review  of  the  implementation.  Keep 
the  following  guidance  in  mind  when  making  this  determination: 

•  Check  Progress  of  Implementation.  Before  you  move  to  the  next  step  of 
the  process  for  a  formal  review,  you  need  to  ensure  that  the  implemen¬ 
tation  has  been  completed  to  such  a  point  that  it  makes  sense  to  pro¬ 
ceed  with  the  next  activity.  If  you  stop  implementation  too  early,  before 
the  technology  has  had  a  chance  to  generate  improvements,  you  risk 
reporting  benefits  that  do  not  accurately  portray  what  the  technology 
is  capable  of  providing  your  organization.  If  you  wait  too  long,  you  risk 
dampening  Ae  enthusiasm  for  the  change  or  losing  management 
commitment  by  not  publicizing  success  stories  early  enough. 
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If  you  do  not  make  the  expected  progress,  find  out  what  has  happened. 
Slowed  progress  might  be  due  to  problems  in  several  areas:  the  imple¬ 
mentation  plan,  producer  support,  political  and  management  suf^rt, 
user  buy-in,  unexpected  or  expected  risks,  the  technology  itself,  or  the 
technology’s  interface  to  the  environment.  Stop  or  slow  down  the  im¬ 
plementation;  determine  how  to  resolve  the  problems;  and  replan,  re¬ 
formulate,  or  reperform  certain  tasks  to  resolve  the  problems.  Then 
continue  the  implementation. 

•  ..Assess  QjualUalife  and  QuantUathe  Pn^^.  Ongoing  implementation 
assessment  should  examine  not  only  quandtathrc  progress  towards  the 
implementation  goals  (e.g.,  how  many  lines  of  code  are  being  written 
using  the  new  technology  versus  the  old),  but  also  whether  the  technol¬ 
ogy  fits  the  users’  needs  and  expectations  in  a  qualitative  sense.  Is  the 
technology  being  used  in  ways  that  support  the  transfer  goals?  Does 
the  implementation  maximize  the  technology’s  potential? 

Figure  6-3  graphically  depicts  quantitative  as  well  as  qualitative 
assessments.  The  productivity  and  quality  targets  in  this  figure  would 
have  come  directty  firom  your  understanding  of  the  expected  benefits. 


Productivity 

Figure  6-3.  Assessing  Quantitative  and  Qualitative  Progress 
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4.  Identify  and  Analjnce  Risks  Associated  ^th  Imidenientation.  You  need 
to  address  any  risks  identified  in  the  risk  management  plan  as  th^  occur 
and  stay  on  top  of  any  new  risks  that  occur  during  the  implementation.  You 
should  document  the  results  of  this  task  in  your  risk  management  plan. 
This  task  lists  some  risks  that  may  occur  during  implementation;  you 
should  refer  to  the  Analyze  and  Resolve  Risks  activity  for  detailed 
guidance  on  how  to  identify,  analyze,  and  avert  risks. 

You  will  not  perform  this  task  in  (fycles  1  and  2. 

You  need  to  stay  on  top  of  risks  documented  in  the  risk  management  plan 
for  the  cycle  and  keep  your  eyes  open  for  new  risks  that  may  occur.  The 
following  are  some  common  implementation  risks: 

•  End  users  do  not  feel  they  are  adequately  supported  during  their  first 
days  with  the  technology. 

•  The  technology  does  not  integrate  into  the  environment  as  planned. 

•  End  users  amplain  that,  thou^  they  agree  to  support  the  transfer,  th^r 
are  in  the  middle  of  a  schedule  crunch  and  cannot  use  the  technology  until 
later. 

•  Champions  and  change  agents  start  getting  other  demands  for  their 
time. 

•  Sponsors  are  nervous  about  spending  resources  without  ai^  immediate, 
perceived  benefit 

Other  common  risks  associated  with  stakeholder  resistance  to  the  transfer 
are  listed  in  Ikble  6-1  in  Iksk  3  in  the  Implement  activity. 

If  a  risk  occurs,  you  have  several  options  for  how  to  proceed.  Hie  following 
list  describes  your  options,  based  on  the  severity  and  number  of  risks: 

•  Minor  Risks.  If  you  do  not  feel  that  a  risk  will  have  a  major  impact  on 
the  cycle  or  the  transfer,  and  there  are  not  a  large  number  of  risks  oc¬ 
curring,  then  you  should  address  the  risk  the  best  you  can  and  continue 
the  implementation  for  the  cycle. 

•  M^or  Ksks.  If  a  risk  is  severe  (e.g.,  the  technology  cannot  be  used  at  all 
because  of  integration  problems  or  a  k^r  sponsor  is  transferred  out  of 
the  organizationX  then  you  may  want  to  stop  the  cycle’s  implementation 
to  understand  the  impact  on  die  transfer. 

•  Large  Number  of  Risks.  If  a  large  number  of  risks  are  occurring,  even 
though  any  single  one  may  not  be  too  severe,  then  you  may  want  to  stop 
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the  transfer  to  try  to  understand  why  the  risks  are  occurring  and  >i^t 
the  impact  is  on  the  transfer. 


Keep  in  mind  that  stopping  the  transfer  in  the  middle  of  the  implonoitation 
can  have  an  adverse  afE^  on  stakeholder’s  attitudes  toward  the  transfer.  You 
should  not  make  the  decision  without  first  getting  stakeholder  buy-in  to  the 
dedsioa 


SiopCriteru 


You  should  stop  this  activity  when  the  implementation  for  this  cycle  has 
been  completed  as  defined  in  the  implementation  plan,  or  you  and  other 
stakeholders  agree  that  a  formal  review  of  the  implementation’s  progress 
needs  to  be  performed. 


teDoM: 


63  REVIEW  TECHNOLOGY  IMPLEMENTATION 


This  activity  begins  at  the  end  of  Step  4,  Implement  'Rchndogy. 


OVSRVIEW 

Your  objectives  in  this  surtivity  are  to  collect  and  review  the  process  assets 
and  the  lessons  learned  generated  during  the  implementaticm.  You  will  use 
this  information  in  the  next  step  to  formally  review  the  progress  of  the 
current  cycle’s  implementation. 

You  will  not  perform  this  activity  until  the  implemratation  for  the  current 
cycle  has  met  the  success  criteria  defined  in  the  implementation  plan. 


Stakt  Crtteru 


You  should  start  this  activity  when  you  have: 

•  An  approved,  detailed  implementation  plan 

•  A  risk  management  plan 

•  Data  on  the  progress  of  the  implementation 


Tasks 


$ 


In  this  activity,  you  will  collect  and  review  process  assets  and  document 
the  lessons  learned  during  the  implementauon. 

If  this  transfer  is  part  of  a  process  improvement  effort,  then  you  need  to 
involve  the  Process  Group  in  this  activity.  Depending  on  your  situation, 
the  Process  Group  will  either  be  the  sponsors  or  the  champions. 

1.  Collect  and  Review  Process  Assets.  During  the  implementation,  change 
agents,  champions,  end  users,  and  possibty  even  sponsors  will  develop  do¬ 
cuments— including  memos,  policies  and  procedures,  and  reports—  that 
support  the  implementation.  For  example,  if  you  are  transferring  in  a  new 
electronic  mail  system,  you  may  have  developed  a  set  of  directions  for  how 
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to  send  and  receive  mail  In  addition,  you  have  devd(^)ed  a  transfer  plan, 
a  risk  management  plan,  and  an  implementation  plan  rdated  to  the 
transfer  and  cycle.  These  documents  are  called  process  assets. 


Cycle  1,2  You  will  not  perform  this  task  in  Cycles  1  and  2. 

QckN  You  need  to  cdlect  the  assets  devdoped  during  each  cyde  and  have  them 
reviewed  by  the  stakeholders  identifi^  in  the  BuQd/Rehifoice  Sptmsoship 
and  Foundarim  activity.  Each  stakehdder  should  review  the  asset  for  accura¬ 
cy  and  completeness.  Your  stakdioldas  in  this  cycle  are  the  change  agents, 
champicHis,  end  users,  and  spcmsors  identified  in  the  Build/Rrinfinoe  Spon¬ 
sorship  and  Foundatimi  activity.  You  should  incorporate  die  comments  fitim 
the  review  in  the  process  assets  as  appropriate. 


2.  Collect  and  Review  Cycle-Levd  Lessons  Learned.  As  the  implementatitm 
progresses,  change  agents,  champimis,  aid  users,  and  sponsors  will  learn 
what  works  and  what  does  not  worit  r^ardipg  the  implementatimi  d  the 
technology.  These  rycle-level  lessons  learned,  whidi  are  tied  to  the  spedfic 
technology,  process  activity,  or  organizational  unit  invtdved  in  the  current 
cycle’s  implemoitation,  need  to  be  cdlected  and  reviewed  in  this  task.  Strate¬ 
gic-level  lessons  learned,  m  how  the  current  tyde’s  lessons  learned  will  impact 
the  overall  transfer  or  the  organization’s  overaQ  transfer  process,  will  be 
identified  in  the  Review  Progress  activity. 


Cycle  1,2  You  will  not  perform  this  task  in  Cycles  1  and  2. 


Cycle  N  Cycle-level  lessons  learned,  which  might  be  tied  to  the  specific  technology 
or  to  the  specific  part  of  the  organization  or  process  being  changed,  must 
be  collected,  documented,  and  reviewed  by  the  transfer’s  stakeholders. 
Each  stakeholder  should  review  the  lessons  learned  for  applicability  to 
their  own  role  in  the  transfer  process.  Your  stakeholders  in  this  cycle  are 
the  change  agents,  champions,  end  users,  and  sponsors  identified  in  the 
Build/Reinforce  Sponsorship  and  Foundation  activity. 


Stop  Criteua 


You  should  stop  this  activity  when  you  have  collected  and  the  stakehdders 
have  reviewed  the  process  assets  and  cycle-level  lessons  learned  generated 
by  the  ciurent  tycle’s  implementation. 
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REVIEW  AND  UPDATE  TRANSFER  PLAN 


It  is  a  mistake  to  look  too  far  ahead.  Only  one  link  (rf  the  chain  of  destiny  can  be  handled  at  a  time. 

Winsum  Chuidiill 


Section  (Mtieetiees 

1.  Provide  guidance  for 
fiumally  reviewing  the 
results  of  the  transfsr  to 
date 

2.  Provide  gfudance  for 
igrdatingjdanrdng 
documents 

3.  Provide  guidatKe  for 
deciding  arui  getting 
commitment  <m  vdurt  to 
donext 


Once  the  technology  implementation  for  the  ^cle  has  been  completed,  you 
need  to  review  the  progress  against  the  objectives  in  both  the  implemmita’ 
tion  plan  and  the  technology  strategy.  Bas^  on  this  review,  you  update 
your  plans  and  strategy;  define  reconunendations  for  how  to  proceed;  and, 
if  it  makes  sense  and  you  can  get  commitment,  proceed  with  the  transfer. 
Figure  7-1  shows  the  three  activities  described  in  this  section. 


Fignre  7-L  Review  and  Update  Ihuisfier  Flan  Activities 

You  do  not  need  to  perform  the  DefineAJpdate  Ikansfer  Plan  and  Review 
Progress  activities  Unearly;  however,  you  will  need  to  finish  the  Review 
Progress  activity  before  you  can  completely  define  or  update  the  transfer 
plan.  You  will  perform  the  Commit  to  Proceed  activity  at  the  end  of  the 
step. 


7-1 


7.  Detemuiie  Where  to  Go  Next:  Review  and  Update  IVansfer  Plan 


7.1  REVIEW  PROGRESS 


OvSRVlIW 


This  activity  begins  in  Step  5,  Review  and  Update  liransfer  Plan. 


Your  objectives  in  this  activity  are  to  perform  a  formal  review  of  the 
progress  made  in  the  current  cycle  against  the  (^e  and  transfer  objectives 
and  to  understand  the  impact  of  the  current  cycle’s  lessons  learned  tm  the 
rest  of  the  transfer.  You  will  use  this  information  in  the  DefineAJpdate 
IVansfer  Plan  activiQr  to  define  and/or  update  any  planning  documents 
before  committing  to  proceed. 

You  will  not  perform  tl^se  tasks  until  all  or  part  of  the  implementatimi  has 
been  completed  and  the  process  assets  and  lessons  learned  for  the  cycle 
have  been  reviewed  all  identified  stakeholders. 

Examples  7-1  and  7-2  provide  a  summary  of  an  entire  transfer  experience. 


SxAirr  Criteria 


You  should  start  this  activity  when  you  have: 

•  An  approved  implementation  plan  for  the  c^cle 

•  Approved  transfer  and  (^cle  objectives,  constraints,  and  strategy 

•  Data  and  results  from  the  implementation 

•  Reviewed  process  assets  and  lessons  learned  generated  during  the 
current  cycle’s  implonentation 


Tasks 


You  wiU  compare  the  implementation  progress  to  the  cjclt  and  transfer 
objectives  and  to  the  cycle  success  criteria  collect  data  on  the  transfer  pro¬ 
cess,  analyze  the  lessons  learned  from  the  current  cycle’s  implementation 
for  how  th^  will  impact  the  rest  of  the  transfer,  and  baseline  the  process 
assets  and  the  lessons  learned  documents. 


7.  Determine  Where  to  Go  Nead:  Renew  and  Update  Thnafer  Ptaa 


Charlie,  a  senior  project  lead  at  Jones'  Aircraft,  was  tasked  with  the  proUein  (tf 
figuring  out  how  to  capture  design  decisions  and  ratXHiale  fcNr  reuse  cm  later  projects. 
There  had  been  some  ad  hoc  software  code  reuse  going  on  at  Jones’  Aircraft,  arvl 
maruigement’s  first  step  at  helping  systematize  this  retse  was  to  look  for  ways  to 
capture  design  decisions. 

Recently,  Charlie  had  been  assigned  to  head  a  project  that  was  scheduled  to  start  in 
aiqrronmately  6  montlo.  The  project,  called  MicroControl,  was  re^nsible  for  the 
design  and  implementation  of  software  for  the  control  of  a  (fistributed  system  of 
micn^rooessors.  It  was  part  of  a  larger  contract  within  Jones’  Aircraft  and  therefore 
had  to  integrate  with  other  subsystems  developed  urafer  the  same  contract 
MicroControl  had  a  total  develqpment  time  (with  little  sladc)  of  24  months.  Cliaflie 
saw  this  as  the  perfect  oi^rtunity  for  piloting  a  new  design  cqrture  technok^. 

Before  MicroControl  kicked  in,  Charlie  started  looking  through  journals,  otmtacting 
vendors,  and  talking  with  his  friends  in  the  industry  to  see  wdiat  technologies  were  out 
there  that  could  capture  design  decisions  and  rationale.  Charlie  also  reviewed  and 
analyzed  previous  company  projects  where  handwritten  iwtes  were  the  chief  form  of 
record  keying  to  see  what  type  of  data  was  being  kept  and  how  the  tecod  keeping 
could  be  improved  and  ufilized. 

After  a  couple  of  weeks  of  analysis,  Charlie  fimnd  a  new  technology  (method  and 
tool),  Vis-Oraph,  that  seemed  to  solve  some  of  the  key  problems.  Charlie  analyzed 
Vis-Graph  to  make  sure  it  addressed  the  basic  requirements  set  down  by  Jones’ 
Aircraft’s  management 

The  entire  analysis  of  available  technologies  and  the  detailed  analysis  of  Vis<Jnq>h 
took  Charlie  approximately  3  staff  months  spread  over  a  period  of  6  calendar  months. 

During  each  planning  meeting  of  the  MicroControl  project  team,  Charlie  examined 
the  environment  to  be  used  in  development  In  these  meetings,  Charlie  learned  that 
Vis-Graph  was  not  available  on  the  computing  platform  chosen  for  MicroControL  To 
mitigate  this  risk,  Charlie  talked  with  the  verier  of  Vis-Graph  to  see  if  a  text-only 
version  of  Vis-Graph  could  be  develcqted  that,  while  preserving  the  methodology  and 
the  basic  functionality  of  the  technok^,  would  be  hardware  independent 
Vis-Graph’s  vendor  was  interested  in  developing  such  a  product  since  it  would  expand 
their  potential  customer  base,  and  agreed  to  develop  a  text-only  version  as  long  as 
Charbe  and  his  team  would  use  early  copies  of  the  software  to  test  arxl  find  bugs  in 
the  software. 

Charlie  also  worked  with  the  MicroControl  project  team  to  define  current  work 
practices.  He  analyzed  Vis-Graph  to  understand  how  it  would  impact  integration  with 
the  other  subsystems  being  developed  under  the  contract  and  decided  that  there 
would  be  no  impact  except  for  the  £a^  that  the  teams  developing  the  other  subitems 
T^ld  have  to  “leam”  Vis-Graph  to  the  extent  that  they  could  understand  Vis-Graph’s 
design  output  during  integration  planning  meetings. 


Example  7-L  Summary  of  an  Entire  Transfer  (Part  1  of  2) 
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Starting  immediately  after  the  Vis-Graph  selection,  Charlie  used  one-on-one 
interviews  with  management  from  all  affected  areas  to  gain  buy-in  to  the  technc^ogy. 
He  also  spent  time  with  the  MicroControl  project  team  and  used  demonstrations, 
prototypes,  aitd  related  experiences  both  to  ensure  the  q^bcability  of  '^s-Graph  as 
well  as  convince  the  team  to  use  it  In  addition,  throi^hout  the  implementation, 
Charlie  continually  acted  as  an  interface  to  management  (especially  mam^ment 
outside  the  software  development  organization)  to  inform  them  (rf  the  progress  and 
to  ensure  them  of  a  positive  return  on  the  investment  they  vmre  making.  Charlie 
answered  management’s  questions  with  reports  on  how  well  the  design  was  being 
evaluated  for  quality  using  the  Vis-Gr^h  technology  and  how  this  would  pay  oB 
when  customer  (klivery  time  came. 

All  in  all,  Charlie  spent  approximately  30  staff-days  spread  over  an  18-month  period 
to  sell  management  on  the  Vis-Graph  technolo^. 

When  implementation  time  came,  the  text  version  of  Vis-Graph  developed  by  the 
vendor  was  installed  on  all  of  the  computers  being  used  by  the  MicroControl  project 
team.  In  addition,  as  part  of  the  implementation,  CharUe: 

•  Defined  an  incremental  approach  to  the  implementation  where,  as  eadi 
stage  in  the  life  cycle  was  reached  by  the  MicroControl  project  team, 
Charlie  would  introduce  and  train  that  portion  of  Vis-Gr^h  to  the  team. 

•  Modified  the  vendor’s  standard  training  course  to  concentrate  on  the 
methodology  since  the  project  was  using  a  text-only  version  of  the 
technology.  Training  schedules  were  ad  hoc  in  nature  since  Charlie  was  a 
working  member  of  the  development  team. 

•  Ensured  that  design  meetings  always  used  Vis-Graph  as  the 
documentation  and  methodology-control  communication  mechanism  and 
ensured  that  the  implementation  of  Vis-Graph  was  integrated  into  the 
MicroControl  project  team’s  schedule. 

•  Kept  track  of  the  time  it  took  to  be  trained  and  to  use  Vis-Gr^h  for  all 
decision  meetiirgs.  The  estimated  time  for  this  was  about  1  staff-week  to 
learn  Vis-Graph  and  the  methodology  and  about  3  staff-months  to 
transform  the  data  fiom  the  simple,  text-oriented  version  to  the  full-scale 
version  and  analyze  the  data  for  results. 

:  Continually  recorded  data  related  to  how  much  time  was  spent  using 

Vis-Graph  and  the  methodology  in  order  to  be  able  to  measure  benefits 
against  costs  at  the  end  of  the  MicroControl  project 

Charlie  documented  and  presented  to  management  his  observations  about 
Vis-Graph  use;  there  was  increased  potential  for  code  reuse  because  of  the  c^ture 
of  design  decisions  that  might  be  applicable  to  other  projects;  Vis-Graph  was  used 
to  help  produce  MicroControl  project  management  reports;  meetings  grew  shorter 
because  team  members  used  the  methodology  to  "remember”  the  open  issues;  other 
organizational  units  became  familiar  with  the  technology,  though  they  did  not 
necessarily  adopt  it;  and,  most  important,  the  MicroControl  project  team  reported 
a  savings  of  three  to  six  times  the  invested  effort  for  errors  found  early  on  the  design 
that  would  have  been  costly  to  fix  after  delivery. 


Example  7-2  Summary  of  an  Entire  Tnnsfer  (Part  2  of  2) 


7.  Detennine  Where  to  Go  Next:  Review  uid  Update  'Ransfer  Plan 


1.  Compare  Inufriementation  Data  to  Objectives.  You  med  to  understand 
the  progress  made  during  this  cycle’s  implementation  ccnnpared  to  the 
success  criteria  made  in  the  transfer  plan  and  to  the  success  criteria  and 
the  predictions  for  progress  against  the  success  criteria  documented  in  the 
implementation  plan  for  this  cycle. 

Qfcle  1,2  You  will  not  perform  this  task  in  Cycles  1  and  2. 

Cycle  N  Analyze  the  data  gathered  during  the  implementation  for  the  following: 

•  End  User  Saiisfaetion.  Was  the  implementation  considered  a  success 
by  the  end  users?  Were  they  satisfied  with  how  the  technology  worked? 
Did  they  feel  that  th^  were  adequately  trained  and  supported?  If 
shortcomings  of  the  technology  or  the  implementation  mechanisms 
are  identified,  then  these  need  to  be  addressed  in  the  transfer  strategy 
and  futiure  cycle  strategies. 

•  Technology  Impact.  Was  the  technology  used  to  its  fullest  extent?  Were 
there  key  features  of  the  technology  that  were  not  used?  Were  all  of  the 
key  features  used,  yet  the  expected  impact  on  the  process  was  not 
made?  If  a  key  feature  is  never  used  (maybe  the  users  are  uncomfort¬ 
able  with  that  featureX  then  you  need  to  understand  why  this  has  oc¬ 
curred  and  address  it  in  future  cycles.  However,  if  all  kqr  features  are 
used,  but  the  expected  impact  was  not  made,  then  you  either  need  to 
lower  stakeholder  expectations  about  the  speed  at  which  the  technolo¬ 
gy  will  show  benefits  or  plan  to  address  this  issue  in  the  next  cycle.  For 
example,  you  may  want  to  do  a  study  to  try  to  understand  the  reason 
why  the  technology  is  not  making  an  impact  (maybe  the  users  do  not 
realize  they  are  using  the  technology  incorrectly). 


•  Sponsor  Satiifaction.  the  implementation  considered  a  success  by 

the  sponsors?  Do  they  feel  that  th^  either  have  or  are  getting  a  positive 
return  on  their  investment  in  the  transfer? 

•  Dran^er  Shrategy.  Did  the  realities  of  the  implementation  stray  firom 
the  original  strategy?  For  example,  maybe  the  strategy  called  for  a  pilot 
of  the  technology  on  one  project  before  moving  to  more  of  the  organiza¬ 
tion  but,  in  realiQr,  this  technology  is  not  conducive  to  being  used  on 
a  trial  basis  because  it  requires  cooperation  from  multiple  support 
functions  (e.g.,  network  support,  accounting)  to  be  most  effective. 

•  Tirantfer  Success  Criteria  and  Objecthes.  Did  the  implementation  make 
progress  against  the  transfer  success  criteria  and  objectives?  If  there 
was  no  progress,  then  you  need  to  carefully  look  at  your  objectives  for 
the  next  cycle.  You  can  not  afford  to  spend  resources  and  time  on  a 
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transfer  without  making  any  progress  toward  your  goal.  Your  best  bet 
will  be  to  develop  a  next-cycle  strategy  that  stands  a  high  chance  of 
making  progress  quickly.  Alternatively,  you  can  alter  your  transfer 
success  criteria  objectives,  though  that  might  start  making  stakehold¬ 
ers  suspicious  of  any  other  transfer  plans  that  have  been  developed. 
However,  please  keep  in  mind  that  since  everybody  has  bought  in  to 
the  current  plans  at  each  milestone  in  the  process,  everybody  will  be 
looking  for  the  best  way  to  proceed.  In  addition,  you  can  use  this 
knowledge  as  lessons  learned  when  you  modify  your  objectives. 

•  Cycle  Strategy  and  Objectives.  Did  the  implementation  make  progress 
against  the  cycle  objectives?  If  not,  or  if  progress  was  not  as  much  as 
expected,  then  you  should  use  that  information  as  lessons  learned 
when  you  define  your  objectives  for  the  nect  cycle  (and  not  make  them 
as  ambitious).  Did  the  cycle  strategy  turn  out  to  be  the  correct  one  to 
follow  or  did  the  realities  of  the  implementation  deviate  from  the  strat¬ 
egy?  Again,  the  lessons  learned  from  the  current  cycle  can  be  used  in 
defining  the  objectives  and  strategy  for  the  next  cycle. 

•  Other  Impacts.  You  need  to  analyze  the  results  of  the  implementation 
for  other  impacts  that  you  might  not  have  foreseen  in  the  planning 
process.  These  other  impacts  include; 

-  Indirect  Impacts.  A  new  technology  tends  to  have  a  wider  effect 
beyond  the  targeted  impacts.  This  may  include  permanent  changes 
in  job  duties,  organizational  structures  and  processes,  or  skill 
demands.  Comparativefy  analyze  the  implementation  in  these 
areas. 

-  Implementation  Processes.  Among  the  impacts  of  implementing 
new  technology  are  those  that  are  tied  to  the  implementation  pro¬ 
cess  itself,  frx  effect,  the  before-versus-after  distmbances  of 
organizational  life,  and  the  qualitative  (or  quantitative)  costs. 

Document  your  anafysis  in  a  lessons-leamed  document.  Include  analyses 
of  risks  and  whether  risk  aversion  plans  were  successful.  Figure  7-2  shows 
an  example  '^f  different  outcomes  for  a  sample  set  of  measures.  Example 
7-3  describes  a  case  where  there  were  multiple  successful  outcomes  from 
the  implementation  of  a  single  tool. 

2.  Collect  Data  on  Technology  Ikansfer  Process.  To  improve  the  way  your 
organization  transfers  technology,  you  need  to  collect  data  across  multiple 
transfers.  From  this  data,  you  can; 

•  Identify  transfer  activities  needing  improvements  by  identifying  those 
process  steps  that  are  consistently  costly  and/or  problematic. 
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Cycle  7,2 


Cycle  N 


Figure  7-2  DifEerent  ImplementatkMi  Outcomes 


General  Ineitia  Company  (GIC)  recently  impleniented  a  Configontion 
Management  Ibol  and  has  evoh^  a  set  of  measnnes  to  assess  the  impact  of  the  tool, 
as  well  as  provide  a  greater  level  of  precision  in  the  management  of  its  system  design 
fiiiiction. 

Both  quantitative  and  qualitative  measures  are  used.  For  example,  managers  are  now 
systematically  “docking”  the  time  from  initial  concept  to  prototype  system.  Other, 
more  qualitative  indexes  suggest  that  the  level  of  communication  across  disc^lines 
and  sub-groups  has  increased  significantly  as  a  result  of  the  tool  implementation  The 
materials  management  group  trades  the  projected  bills  of  materials  versus  as-built 
product  descriptions.  Disciplined  use  of  the  configuration  management  tool  is 
improving  the  designers  ability  to  accurately  forecast  material  requirements. 


Example  7-3.  A  Case  of  Multiple  Outcomes 

•  Identify  how  much  it  costs  to  plan  and  implement  a  technology 
transfer.  By  understanding  these  costs,  your  organization  can  make 
more  informed  decisions  on  whether  to  transfer  a  technology  (e.g.,  will 
the  transfer  cost  more  than  the  benefits  expected  from  the  technolo¬ 
gy?)  and  whether  to  institutionalize  a  defined  technology  transfer 
process. 

Based  on  the  data  collected  in  the  activities  in  this  cycle,  collect  the 

following  measurements: 

•  Status  of  sponsorship  and  project  commitment  to  the  technology 

•  Cost  and  effort  spent  on  management  presentations  and  selling 
management  and  staff  on  the  transfer 

•  Cost  and  effort  spent  on  analyzing  and  resolving  risks 

•  Number  of  replans  performed  and  the  impact  on  the  transfer 

Based  on  the  data  collected  in  the  activities  in  this  cycle,  collect  the 

following  measurements: 

•  Status  of  sponsorship  and  project  commitment  to  the  technology 

•  Cost  and  effort  spent  on  management  presentations  and  selling 
management  and  staff  on  the  transfer 
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•  Cost  and  effort  spent  on  analyzing  and  resolving  risks 

•  Cost  and  effort  expended  on  planning  the  technology  implementation 

•  Number  of  replans  performed  and  the  impact  on  the  transfer 

•  Estimate  versus  actual  for  implementation  schedule,  costs,  and  effort 

•  Cost  and  effort  eepended  on  support  activities,  by  type 

•  Cost  and  effort  expended  on  integration  activities 

•  Cost  and  effort  expended  on  staff  training 

•  Results  of  training  evaluations  and  reviews 

•  Number  of  training  attendees 

As  you  collect  data  across  multiple  cycles  in  the  current  transfer,  you  can 
identify  consistently  risky  areas  and  incorporate  that  into  your  transfer-le¬ 
vel  lessons  learned  (see  'Risk  3) .  In  addition,  store  this  data  in  a  single  loca¬ 
tion  along  with  data  saved  from  other  transfers,  so  that  it  can  be  used  in 
planning  future  transfers  and  in  improving  your  organization’s  technology 
transfer  process. 

3.  Collect  Ihinsfer-Level  Lessons  Learaed.  The  previous  activify.  Review 
Ibchnology  Implementation,  collected  and  reviewed  cycle-level  lessons 
learned;  these  lessons  learned  were  related  to  the  specific  technology,  pro¬ 
cess  activity  or  organizational  unit  involved  in  the  current  code’s  imple¬ 
mentation.  In  this  activify,  you  need  to  understand  how  these  cycle-level 
lessons  learned,  along  with  the  data  coUected  on  the  transfer  process  in 
Iksks  1  and  2  of  this  activify,  might  affect  future  cycles  and  document  this 
in  transfer-level  lessons  learned.  For  example,  a  (fycle-level  lessons  learned 
may  be  that  each  user  needed  to  have  1  hour  of  hand-holding  before  feeling 
comfortable  with  the  technology.  This  might  translate  into  a  transfer-level 
lessons  learned  that  requires  all  new  users  to  have  1  hom:  of  hand-holding 
by  an  expert.  These  transfer-level  lessons  learned  might  also  impact  future 
transfers  within  the  organization. 

You  will  not  perform  this  task  in  Cycles  1  and  2. 

In  each  cycle,  you  need  to  collect  the  (fycle-level  lessons  learned  and 
determine  how  they  might  affect  future  (fycles  of  the  transfer.  You  need  to 
document  these  lessons  learned  and  give  them  to  your  stakeholders  for 
their  review.  Each  stakeholder  should  review  the  lessons  learned  for  appli¬ 
cability  to  their  own  role  in  the  transfer  process  and  for  agreement  that 
these  lessons  learned  should  be  applied  in  future  cycles. 


Cycle  1,2 
Cycle  N 
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4.  Baseline  Process  Assets  and  Lessons  Learned.  You  need  to  baseline  die 
process  assets  generated  during  the  current  (^le’s  implemratation  and 
baseline  both  the  cycle  and  transfer  lessens  teamed. 

Cycle  1,2  You  will  not  perform  this  task  in  Cycles  1  and  2. 

Cycle  N  In  the  previous  activity.  Review  'technology  Implementation,  you  cedtected 

and  st^holders  reviewed  process  assets  and  eycle-level  lessons  learned. 
In  the  previous  task  of  this  activity,  you  cdlected  and  stakehdders  re¬ 
viewed  transfer-level  lessons  learned.  In  this  task,  you  need  to  baseline 
these  materials  by  putting  them  through  your  organization’s  configurati(Mi 
management  system;  that  is,  you  need  to  make  sure  that  you  save  the  latest 
version  of  each  document  for  possible  reference  in  a  later  cycle  or  later 
transfer. 


Stop  Criteru 


You  should  stop  this  activity  when  you  have; 

•  Documented  the  results  of  a  formal  review  of  the  implementation 
progress,  including  identifying  transfer-level  lessons  learned 

•  Baselined  all  of  the  process  asse'^s  and  lessons  learned  generated 
during  this  cycle 
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10.  DEFINE/UPDATE  TRANSFER  PLAN 


This  activity  begins  in  Step  5,  Review  and  Update  Ihuisfer  Plan. 


Overview 


Start  Crtteru 


Your  objective  in  this  activity  is  to  define  and/or  update  the  transfer  plan 
based  on  the  results  of  the  current  (tycle.  The  transfer  plan  is  a  living 
document  that  should  be  updated  in  each  cycle  of  the  transfer  process. 

The  information  used  to  update  the  plan  will  come  from  many  sources, 
depending  on  where  you  are  in  the  process.  These  source  include  any  risk 
analysis  done  in  the  Analyze  and  Resolve  Risks  activity;  any  implementa¬ 
tion  progress  made  in  the  Implement  activity;  and  your  anatysis  of  the 
implementation  progress  done  in  the  Review  Progress  activity. 


You  should  start  this  criteria  you  have: 

•  An  approved  transfer  strategy,  objectives,  and  constraints 

•  An  approved  cycle  strategy,  objectives,  and  constraints 

•  The  results  of  the  risk  analysis  done  in  the  Analyze  and  Resolve  Risks 
activity 

•  Data  gathered  d\iring  any  implementation  done  in  this  cycle,  including 
(tycle-level  lessons  learned  and  process  assets 

•  Any  results  from  the  Review  Progress  activity,  including  transfer-level 
lessons  learned 

•  If  a  continuing  transfer,  the  transfer  plan  from  the  previous  cycle 


Tasks 


You  need  to  define  recommendations  and  define  and/or  update  the 
transfer  plan,  including  the  budget  and  schedule,  and  the  plan  for  the  first 
three  steps  of  the  next  cycle.  The  transfer  plan  will  be  the  basis  by  ^ch 
stakeholders  will  agree  to  continue  or  not  continue  the  transfer. 
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1.  Define  Recommendations  and  DeiineAJpdate  Dransfer  Plan.  Define 
your  recoininendation(s)  for  how  the  transfer  should  proceed  in  tlM  next 
cycle  and  update  the  transfer  plan  accordingly,  including  the  budget  and 
schedule  and  the  plan  for  the  next  cycte. 

In  Cycle  1,  you  will  plan  the  entire  transfer  and  the  next  cyck  based  on  the 
approved  transfer  strategy,  objectives,  and  constraints,  and  m  the  results 
of  the  risk  analysis  performed  in  tl^  Anafyze  and  Resolve  Risks  activity. 
Specificalty,  you  need  to: 

•  Develop  your  long-range,  strategic  plan  for  performing  the  transfv. 
This  will  include  the  long-range  goals  for  the  transfen  the  general  order 
in  which  the  transfer  will  be  performed  (that  is,  which  parts  of  the  orga¬ 
nization  will  be  affected  and  in  which  order^  the  stalmhdiders  needed 
for  the  transfer,  both  short-  and  long-term;  and  who  is  responsible  for 
the  transfer. 

•  Develop  success  criteria  against  which  you  will  measure  the  transfer. 
You  should  take  the  expected  benefits  (see  Iksk  3  in  the  Define/Update 
Hansfer  Strategies  activity)  into  consideration  when  developing  the 
success  criteria. 

•  Develop  a  budget  and  schedule  for  the  transfer. 

•  Plan  for  the  first  three  steps  of  the  next  cycle.  That  is,  you  need  to 
allocate  resources  and  budget  to  address  sponsorship  and  foundation 
issues,  develop  the  cycle  plan,  understand  the  process,  analyze  and 
avert  risks,  select  the  cycle  strategy,  and  plan  the  implementation. 

When  defining  your  transfer  plan,  you  need  to  make  sure  that  you  meet 
both  the  technical  and  the  human  objectives  of  the  transfer.  You  can  have 
the  technology  integrated  perfectly  and  provide  all  the  necessary  training, 
but  still  have  a  failure  if  you  do  not  realize  that  a  new  technology  requires 
people  to  change  their  lives  and  they  will  naturally  resist  that  change.  You 
need  to  address  this  in  your  plan  by  allocating  adequate  time  and  resources 
to  selling  the  transfer,  supporting  the  users,  and  allowing  the  users  to 
participate  in  the  review  and  decision-making  processes. 

Cycle  2,  you  will  update  the  transfer  plan  (including  budget  and 
schedule  if  necessary)  developed  in  the  first  cycle  based  on  any  changes 
needed  due  to  changes  in  sponsorship  or  organizational  readiness  issues. 
For  example,  in  the  first  (tycle  you  may  have  expected  not  to  get  account¬ 
ing’s  approval  for  the  transfer;  however,  in  the  process  of  understanding 
organizational  readiness  you  may  have  learned  that  the  accoimting  office 
had  been  planning  to  change  soon  anyway  and  that  you  will  be  able  to  work 


^  Sponsor 


Giange 

Agent 


Champion 


& 


End  User 


7-11 


7.  Detennine  Where  to  Go  Next:  Review  and  Update  HraHfer  Plan 


together  on  the  transfer.  This  type  of  change  needs  to  be  incorporated  into 
the  transfer  plan. 

Again,  as  in  the  first  cycle,  you  need  to  plan  for  the  first  three  steps  ci  the 
next  cycle  in  this  activity. 

C!yck  N  When  updating  the  transfer  plan,  you  will  heavily  use  the  analysis  (tf  the 
implementation  you  perfom^  in  the  Review  Progress  activi^,  induding 
the  transfer-level  lessons  learned  you  generated,  and  as  much  quantified 
justification  as  possibte  as  the  basis  for  your  changes.  You  will  update  the 
transfer  plan,  update  the  budget  and  schedule,  and  plan  the  first  three 
steps  of  the  next  (^cle. 

•  Update  nantfer  Plan.  Based  on  the  results  of  the  implementation,  aiqr 
of  several  recomn^dation  scenarios  might  be  suiti^le  and  should  be 
incorporated  into  the  transfer  plan  where  it  will  feed  into  the  definition 
of  the  objectives  and  strategy  for  the  next  cycle: 

-  Hie  implementation  went  well  and  it  should  be  caqianded  to  more 
of  the  organization  as  is  (opening  the  door  to  institutionalization 
of  the  technology). 

-  The  organization  should  reconduct  the  implementation  to  iron  out 
more  bugs.  This  is  the  situation  when  the  implementatitm  was  in¬ 
complete  or  had  difGculties.  You  may  recommend  in  the  transfer 
plan  that  the  next  c^cle  focus  on  reevaluating  peoples’  assignments 
to  the  transfer  and  seeking  new  champions. 

-  The  organization  should  reconsider  the  technology  selected 
because,  though  there  is  a  need  or  opportunity,  the  wrrmg  technol¬ 
ogy  was  select.  Fbr  example,  maybe  the  impacts  to  productivity 
and  quality  were  not  what  you  had  expected.  However,  you  do  not 
want  to  be  changing  technologies  without  first  serious  consider¬ 
ation  and  complete  stakeholder  buy-in;  users  will  be  waxy  of  chang¬ 
ing  to  a  new  technology  after  investing  time  in  the  first  techndogy 
that  is  now  not  going  to  be  used. 

-  The  organization  should  reevaluate  the  entire  situation  because 
the  implementation  was  a  failure. 

-  The  implementation  should  be  considered  complete  because  the 
goal  of  the  implementation  was  to  successful^  use  the  technology 
for  a  fixed  period  of  time,  and  that  goal  was  achieved.  No  addition¬ 
al  effort  should  be  expended  on  the  transfer,  except  for  the  develop¬ 
ment  of  a  lessons-Ieamed  report  recounting  what  worked  and  what 
did  not  work  in  the  implementation. 
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The  imptementation  went  well  and  should  be  expanded  to  more  d 
the  organization,  though  with  some  needed  minor  dianges.  Fnr 
example,  there  may  be  additional  benefit  gained  in  adjusting  the 
technology  interfitce. 


A  major  danger  in  moving  to  institutionalization  is  that  later 
implementatitMis  may  not  achieve  the  same  success  as  the  initial 
mentatioa  More  often  than  not,  the  steps  taken  in  the  original  detailed 
implementation  plan  are  not  fdlowed  in  subsequent  implementation 
efforts.  This  can  be  partial]^  avoided  by  assigning  staff  to  support  and 
monitor  the  implementatimi  of  the  tedmology  as  it  is  initial^  tried  on 
new  projects  and  by  maintaining  a  high  level  of  visibility  into  die 
continuing  benefits  received  from  the  new  technology. 


•  Update  Budget  and  ScMule.  When  updating  the  budget  and  schedule 
for  the  transfer,  you  need  to  allocate  time  and  resource  ctmtingendes 
to  handle  such  problems  as  emerging  opposition  to  the  transfer,  fading 
management  support,  interference  of  other  seemingly  independent 
changes,  and  system  troubles.  It  is  important  that  the  transfer  plan  an- 
ticipate  and  budget  contingencies  for  solving  these  problems.  Example 
7-4  describes  how  inadequate  contingencies  for  ongoing  support 
negativety  affected  the  transfer  of  a  technology. 


1 


AirCrame  Ltd.  decides  to  transfer,  initially  on  a  trial  basis,  a  new  software  design 
methodology  to  address  a  histoty  of  software  bags  that  traces  bade  to  fealty 
designs  (whkh  each  project  did  differently  on  an  ad  hoc  basis).  A  site  lioense  ftnr 
the  metlKxl  is  parchased,  and  training  is  provided  for  all  staff  in  the  trial  iHOject 
Hansfer  assistance  and  hand-holding  is  provided  for  the  trial  project,  arid  there 
are  extensive  efforts  to  iron  oat  earty  misconcqnions  and  documentation 
liniitations.  The  ^sign  method  is  a  success  on  the  trial  project,  plans  are  drawn 
op  and  transferred  to  train  everybody  in  the  company  on  the  new  design  method, 
and  the  transfer  team  is  disbanded. 

Eighteen  months  later.  Airframe  has  erqrerienced  a  20%  turnover  of  staff  in 
certain  key  divisions  and  is  in  the  process  of  trying  to  get  their  new  employees  iq> 
to  speed  on  their  sttftware  development  processes.  One  stumbling  blodr  seems  to 
be  the  employees’  difBcnlty  in  understanding  the  new  design  methodology.  No 
indhndual  has  responsibility  for  training  newusers.  The  original  training  matmials 
and  overheads  cannot  be  found.  Since  the  introduction  of  the  method  about  2 
years  earlier,  the  vendor  has  already  released  two  upgrades,  neither  of  which  has 
been  incorporated  into  company  operations.  After  3  years,  nearly  40%  cS 
Airframe’s  employees  are  “new,”  and  the  level  of  effective  use  of  the  new  design 
method  is  neghgt'ble.  In  feet,  most  projects  have  reverted  to  the  old  ad  hoc  vaj 
of  developing  designs. 

After  3  years,  the  method  is  withdrawn  from  Airframe  operations,  and  the  CTO 
judges  the  effort  a  dismal  failure. 


Example  7-4.  A  Case  of  an  Incomplete  Support  Plan 
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•  Pkat  Next  Cyde.  Based  (m  the  results  of  the  ui^>leiiieiitatXMi,  and  on 
the  resulting  impacts  on  the  transfer  plan,  you  need  to  allocate 
resources  and  a  budget  for  the  next  three  steps  the  next  ^de. 


Stot  Camau 

You  should  stop  this  activity  when  you  have  updated  tlw  transfer  plan 
based  cm  the  results  of  the  cunent  cycle. 
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73  CX)MMIT  TO  PROCEED 


This  activity  begins  at  the  end  of  Step  5.  Review  and  Update  Thmsfer  Plan. 


Your  objective  in  this  activity  is  to  get  all  stakehdders  to  conunit  to 
proceed  with  the  transfer  bas^  on  the  transfer  plan  you  defined  in  the 
DefineAJpdate  T’ansfer  Plan  activity.  A  key  part  of  this  activity  is  for  the 
sponsors  to  publicize  their  conunitment  across  the  organizatitm. 

You  should  not  proceed  with  the  transfer  until  you  have  successfiilfy 
completed  this  activity. 


Stakt  Cmteru 


You  should  start  this  activity  when  you  have  a  plan  for  how  the  overall 
transfer  and  the  first  part  of  the  next  cycle  should  be  conducted,  including 
a  budget  and  schedule. 


Tasks 


You  need  to  get  a  conunitment  from  the  stakeholders  to  proceed  with  the 
transfer  based  on  the  transfer  plan. 

If  this  transfer  is  part  of  a  process  improvement  effort,  then  you  need  to 
follow  these  steps: 

•  Get  Commitment  Firom  the  Process  Group.  You  first  need  to  get 
commitment  from  the  Process  Group  managing  the  improvements  on 
how  to  proceed.  You  will  do  this  by  presenting  your  plans  and  recom* 
mendations  to  the  Process  Group  and  getting  their  commitment  on  the 
future  direction  of  the  transfer  given  the  full  context  of  the  process  im¬ 
provement  effort.  The  Process  Group  may  direct  you  to  present  and 
get  conunitment  from  the  Steering  Committee  on  the  direction  of  the 
transfer.  Your  presentation  should  include  the  topics  listed  under  Iksk 
2  of  this  activity,  Obtain  Commitment  From  Sponsors. 

•  Get  Commitment  Fh>m  Jiran^er  Stakdtoiders.  After  you  have  the 
Process  Group’s  commitment,  proceed  with  this  activity,  first  getting 
buy-in  from  the  champions,  change  agents,  and  end  users,  and  then 
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Cycle  I 


Cycle  2...N 


getting  a  ccnnniitment  fi:(»n  any  sponsors  indepencknt  of  the  Process 
Group. 

You  may  need  to  work  between  the  transfer  stakeholders  and  the  Process 
Group  in  order  to  come  to  an  agreement  on  which  directimi  the  transfer 
should  take;  however,  remember  that  you  need  full  consensus  before  pro¬ 
ceeding  or  else  risk  losing  support  for  the  transfer  from  a  critical 
stakeholder. 

1.  Obtain  Commitment  Firom  Champions,  Change  Agents,  and  End 
Users.  Focus  this  task  on  getting  champions,  end  users,  and  change  agents 
to  commit  to  the  plan  and  agree  to  proceed  with  the  transfer.  Sponsorship 
is  more  easily  achieved  if  there  is  buy-in  from  all  the  other  players  involved 
in  the  transfer.  You  may  need  to  go  through  several  iterations  of  the  review 
process  before  they  will  give  their  commitment. 

In  alt  cycles,  you  will  be  looking  for  commitment  to  proceed  with  the 
transfer  based  on  your  transfer  plan  which  describes  the  strategy  for  the 
transfer,  including  a  budget  and  schedule,  and  a  plan  for  proceeding  with 
the  first  three  steps  of  the  next  cycle. 

In  the  first  cycle,  you  need  to  get  commitment  only  from  the  change  agents 
and  champions  who  have  been  developing  the  transfer  plan. 

In  all  other  cycles,  you  need  to  get  commitment  from  all  champions,  change 
agents,  and  end  users  identified  in  the  Build/Reinforce  Sponsorship  and 
Foundation  activity. 

2.  Obtain  Commitment  FVom  Sponsors.  After  you  have  buy-in  from  all 
champions,  change  agents,  and  end  users,  you  need  to  present  your  plan 
to  the  sponsors  for  approval  and  commitment  to  proceed.  Your 
presentation  should  include: 

•  A  description  of  the  plan,  including  likely  transfer  scenario(s)  and 
suggested  assignment  of  responsibility  for  the  transfer 

•  Your  rationale  for  the  plan,  including  justification  for  the  overall 
objectives  of  the  transfer  (both  long-  and  short-term  benefits) 

•  The  impact  of  the  plan  on  the  organization,  especially  the  impact  on 
each  sponsor’s  group 

•  The  estimated  cost  and  time  frame  for  the  plan 

Depending  on  your  situation,  you  may  decide  to  stagger  the  presentations, 
targeting  first  those  sponsors  who  are  more  supportive  in  order  to  build 
up  a  stronger  case  for  those  sponsors  who  are  less  supportive. 


^  Sponsor 


Change 

Agent 


Champion 


End  User 
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You  may  have  several  iterations  in  your  presentation  to  management 
before  you  get  a  final  decision  to  go  ahead  with  the  plan  and  proceed  with 
the  reconunendations.  If  so,  return  as  necessary  to  any  activity  in  this  step 
(Define/Update  'fiansfer  Plan  or  Review  Progress)  to  make  the  changes 
before  getting  their  commitment. 

In  all  cycles,  you  will  be  looking  for  commitment  to  proceed  with  the 
transfer  based  on  your  transfer  plan  which  describes  the  strategy  for  the 
transfer,  including  a  budget  and  schedule,  and  a  plan  for  how  to  proceed 
with  the  first  three  steps  of  the  next  cycle. 

Cycle  1  In  Cycle  1,  you  will  not  perform  this  task  since  you  do  not  have  a  sponsor. 

Cycle  2...N  In  ail  other  cycles,  you  need  to  get  commitment  from  all  authorizing  and 

reinforcing  sponsors. 

3.  Publicize  Commitment.  After  commiting  to  proceed,  the  sponsors  need 
to  publicize  their  commitment  throughout  their  organization  to  keep  ev¬ 
erybody  informed,  to  assure  the  end  users  that  the  transfer  is  important, 
and  to  help  prepare  everybody  for  the  changes  ahead.  To  publicize  approv¬ 
al,  the  sponsors  may  send  a  memorandum  or  electronic  mail,  hold  an  orga¬ 
nization-wide  meeting,  or  hold  a  series  of  briefings  across  the  organization. 

An  important  part  of  this  task  is  for  the  sponsors  to  publicize  why  the 
transfer  is  being  performed;  that  is,  the  current  problems  the  organization 
is  having  and  how  the  technology  will  alleviate  those  problems. 

You  can  use  the  influence  strategy  developed  in  the  Build/Reinforce 
Sponsorship  and  Foundation  activity  in  planning  and  implementing  this 
task. 

Cycle  I  In  Cycle  1,  you  will  not  perform  this  task  since  you  do  not  have  a  sponsor. 

Cycle  2...N  In  later  cycles,  you  should  work  with  the  sponsor  needs  to  publicize  the 

decision  and  their  support  and  commitment  to  the  transfer  to  help  prepare 
everybody  for  the  changes  ahead. 


Stop  Crtteru 

You  are  done  with  the  activity  when: 

•  You  have  commitment  from  all  stakeholders  to  proceed  with  the 
transfer  based  on  the  transfer  plan 

•  The  sponsors  have  publicized  their  commitment  to  the  organization 
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This  page  intmtionally  left  blank. 
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8.  IMPROVING  YOUR 
TECHNOLOGY  TRANSFER  PROCESS 


The  establishment  of  a  technology-transfer  function  was  judged  the  most  profound  of  the  actions  taken. 


Section  Objectives 

1.  Fimide  general 
guidelines  for  improving 
your  organization’s 
tecSmolo^  transfer  process 

2.  Pronde  gtddelines  for 
justifying  fMowirtg  a 
darned  technology  tnmsfer 
process 


Watts  Humphrey,  Tbny  Snyder,  and  Ronald  Willis,  IEEE  Software 

In  contrast  to  Sections  3  through  7  of  this  guidebook,  which  gave  you 
specific  step-by-step  guidance  on  bow  to  transfer  a  particular  technology 
into  your  organization,  this  section  provides  generic  guidelines  for 
improving  your  organization's  overall  technology  transfer  process. 

This  section  assumes  that  your  organization  will  frequently  transfer  in 
technology.  This  section  also  assumes  that  your  organization  can  learn  to 
manage  these  efforts  to  systematically  organize,  learn,  and  optimize  the 
process  over  many  transfers. 


8.1  THE  BIG  PICTURE 


Organizations  differ  widely  in  the  ways  they  address  technology  transfer: 
some  handle  it  as  stressful  episodes;  others  try  to  learn  from  each  transfer 
but  are  poor  at  applying  any  lessons;  and  others  treat  technology  transfer 
as  a  “core  competency”  with  organizational  structures,  processes,  and  in¬ 
centives  aimed  at  maximizing  their  competitive  advantage  in  this  area. 

This  section  provides  strategies  you  can  use  to  improve  your  own 
technology  transfer  process.  You  will  learn  how  you  should,  with  adapta¬ 
tions  for  your  situation,  change  your  organization’s  strategy,  culture, 
structure,  mechanisms,  and  external  relationships. 


Organizational  Context 


Instead  of  viewing  the  technology  transfer  process  as  an  isolated  set  of 
activities  that  you  only  perform  during  a  transfer,  consider  technology 
transfer  as  an  ongoing  function  with  a  permanent  set  of  organizational  pro¬ 
cesses  and  relationships.  From  this  perspective,  technology  transfer  in¬ 
volves  the  managed  exchange  of  information  and  resources  both  within 
your  organization  and  with  related,  external  organizations.  Figure  8-1 
shows  a  number  of  organizations  that  might  affect  a  technology  transfer, 
along  with  the  types  of  information  and  resources  that  may  flow  between 
them. 
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Customer 
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Project  Specification 
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Change  Requests 


Management  Data 
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Product 


Constraints/Standards 
Historical  Data 
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•  Engineering/ 
Management 
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_  .  .  ,  Requirements 
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Management  Data 

•  Subproducts 


♦  I 

Subcontractors 


Figure  8>1.  Organizational  Relationships  to  Technology  Transfer 

When  an  organization  views  technology  transfer  as  an  ongoing  function, 
then  organizational  arrangements  to  handle  technologies  and  technology 
transfers  can  be  instituted  and  improved.  The  next  sections  provide 
guidelines  for  these  organizational  arrangements  in  the  following  areas: 

•  Strategy 

•  Organizational  culture 

•  Organizational  structures  and  infrastructures 

•  Technology  awareness  mechanisms 

•  External  relationships  and  partnerships 

Each  section  briefly  describes  the  relationship  of  each  area  to  technology 
transfer  and  then  lists  guidelines  on  how  to  improve  within  that  area. 


Strategy 


You  transfer  technology  not  for  its  own  sake  but  for  the  advantages,  both 
immediate  and  strategic,  it  provides.  To  maximize  these  advantages,  you 
need  to  concentrate  on  technology  considerations  and  their  role  in  strate¬ 
gic  efforts  and  planm'ng.  In  most  cases,  these  considerations  address  the 
successful  transfer  and  use  of  technology. 
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Be  visionaty  and  aware  of  technology  transfer  in  your  strategic  and 
tactical  planning. 

•  Use  strategic  efforts  as  the  impetus  to  transfer  technology  and  plan 
future  strategic  technology  transfer  efforts.  Current  strategic  efforts 
related  to  technology  include: 

-  Moving  up  the  SEI  CMM  scale 

-  Incorporating  Tbtal  Quality  Management  (TQM)  and  related 
mechanisms  for  involvement  and  improvement 

-  Becoming  certified  under  the  International  Organization  for 
Standardization  (ISO)  9000  series  of  quality  management  system 
standards 

-  Pursuing  the  U.S.  Department  of  Commerce’s  Malcolm  Baldridge 
Quality  Award  or  other  quality  awards 

•  Examine  international  competitiveness  in  your  strategic  planning. 
Consider  both  potential  global  markets  as  well  as  global  technology 
sources. 

•  Become  proactive  in  technology  transfer  by  exploiting  and  retaining 
initiative  to  influence  future  events  (e.g.,  influencing  standards’  direc¬ 
tions);  making  quicker,  better  decisions  regarding  technology  direc¬ 
tions  and  use;  and  achieving  flexibility  to  avoid  adverse  events  (e.g., 
developing  a  culture  of  technological  change  that  allows  you  to  enter 
new  markets  when  old  markets  fade  away). 

•  Consider  technology  and  technology  transfer  needs,  plans,  and 
opportunities  in  planning  the  staff  and  environment  capability  of  your 
organization.  Involve  management  and  staff  who  are  providing 
resources,  sponsoring,  or  promoting  the  use  of  new  technologies. 


Organizational  Culture 

From  an  organizational  viewpoint,  technology  transfer  is  more  than  a 
simple  behavior  that  can  be  called  upon  when  needed.  It  is  a  complec  set 
of  knowledge,  skills,  values,  norms,  behavioral  patterns,  and  ongoing  acti¬ 
vities  that  few  technically  educated  persons  learned  in  school  or  fully  mas¬ 
tered  early  in  the  workplace.  To  maximize  your  organization’s  success  at 
technology  transfer,  you  must  direct  considerable  attention  toward  build¬ 
ing  and  nurturing  a  culture  that  supports  and  encourages  the  process. 

Develop  a  culture  that  supports  technology  transfer. 

•  Establish  management  commitment  from  the  top  down  to  a  culture 
supporting  changes  that  lead  to  improvements  in  practices. 
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•  Establish,  through  a  broad  consensus  process,  an  organizational 
mission  statement  and  a  statement  of  organizational  values  that  recog* 
nize  and  encourage  ongoing  improvement  and  opermess  to  outside 
ideas  and  technology.  Make  sure  your  organization’s  policies  and  pro¬ 
cedures  support  the  new  mission  and  values  statements. 

•  Ensure  that  management  and  staff  understand  the  need  for  technology 
transfer  throughout  the  organization,  including  a  long-term  under¬ 
standing  of  technology’s  position  in  your  business  strategy. 

•  'Brain  management  and  staff  on  technology  transfer  principles  and 
techniques.  This  can  include  training  in  the  entire  technology  transfer 
process,  implementation  planning,  technology  management  or 
product  marketing,  organizational  change,  and  interpersonal  skills. 


Organizational  Structures  and  Infrastructures 

Your  organizational  structure  and  infrastructure  must  change  to 
incorporate  new  transfer  strategies  and  cultural  practices.  These  changes 
may  involve  new  functions  and  groups  or  new  relationships  between  ones 
that  already  exist.  Organizational  structures  deal  with  permanent  or  tem- 
poraiy  departments,  groups,  or  positions  filled  by  staff  members.  Infra¬ 
structure  mechanisms  deal  with  programs,  policies  and  procedures, 
technologies,  or  capabilities  within  your  organization. 

Ensure  organizational  structures  exist  that  support  technology  transfer. 

•  Use  your  human  resource  department  to  ensure  availability  of 
expertise,  skills,  and  training  in  technology  and  technology  transfer. 

•  Create  a  separate  technology  receptor  suborganization  that  identifies 
and  tests  new  technologies  and  helps  bring  them  into  the  organization. 
Consider  many  aspects  in  forming  such  an  organization,  including  its 
relationship  with  the  rest  of  the  organization,  staffing  (including  rota¬ 
tion),  resources,  duties  (to  identify,  not  invent),  organizational 
placement,  and  permanence. 

•  Develop  a  permanent  internal  training  group  to  rapidly  develop  and/or 
customize  training  materials,  successfully  deliver  them,  and  maintain 
ongoing  training  support.  This  requires  specialized  expertise  in 
professional  training  and  instructional  design. 

•  Use  a  process  improvement  group,  such  as  the  SEPG,  to  facilitate  the 
introduction  of  new  technology. 

Ensure  infrastructure  mechanisms  exist  that  support  technology 
transfer. 
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•  Develop  measurement  programs  that  set  baselines  and  measure 
changes  to  the  baseline  from  using  new  technologies.  Read  the  Software 
Measurement  Guidebook  (Software  Productivity  Consortium  1992b) 
for  information  on  how  to  set  up  a  measurement  program  and  refer 
to  the  Technology  Benefits  Model  User  Manual  (So^are  Productivity 
Consortium  1993c)  for  support  on  how  to  estimate  and  maintain  quan* 
titative  data  on  technology  improvements. 

•  Develop  written  guidelines  on  how  to  institutionalize  a  technology;  for 
example,  how  to  build  it  into  budgeting,  infrastructure  procedures,  and 
revised  job  descriptions. 

•  Coordinate  and  refine  the  roles  for  such  areas  as  technical  support, 
configuration  management,  the  technical  libraiy,  and  purchasing. 

•  Create  information  repositories  of  technology  transfer  experiences  to 
assess  the  impact  of  a  change  and  to  identify  how  to  improve  your 
transfer  process.  Capture  both  the  “folklore”  of  local  technology  trans¬ 
fer  cases  and  experiences  of  managers  and  staff  “telling  their  stoiy” 
and  more  objective  data,  such  as  what  transfer  mechanisms  were  used, 
the  role  of  users,  and  the  decision-making  process. 

•  Generating  a  repository  containing  information  on  past  technology 
transfer  experiences  can  be  used  to  help  plan  and  predict  future  trans¬ 
fers.  Information  on  planned  transfers  can  allow  projects  to  integrate 
their  transfer  approaches.  The  repository  does  not  have  to  be  kept  in 
one  central  place,  but  it  should  be  easy  to  access. 

•  Migrate  toward  open  hardware  and  software  environments  that 
support  addition  and/or  modihcation  of  technologies. 

•  Integrate  the  organization’s  technology  transfer  process  with  other 
organization-wide  processes  (e.g.,  TQM)  and  with  any  strategic 
planning  processes  or  groups. 

•  Establish  an  organizational  assessment  and  analysis  capacity,  and  use 
it  regularly. 

•  Consider  ways  that  your  organization  can  distribute  expertise  among 
staff,  reducing  reliance  on  individual  specialists  and  increasing  flexi¬ 
bility,  This  might  include  tuition  reimbursements  for  furthering  educa¬ 
tion,  improving  the  flow  of  information  among  groups,  and  rotating 
staff  across  divisions  and  staff  positions. 


Technology  Awareness  Mechanisms 

Technology  awareness  mechanisms  support  your  new  strategy,  culture, 
and  structure  by  keeping  you  on  top  of  new  technology  developments  and 


8.  Improving  Your  Ttchnology  *&ansfer  ProccM 


by  ensuring  that  you  create  supportive  policies,  procedures,  and  prat^ces. 

Operational  details  focus  on  how  the  organization  will  routinely  perform 

the  business  of  technology  transfer. 

Stay  on  top  of  new  technology  devel<^>nients. 

•  Systematically  access  and  digest  relevant  periodicals,  market  reports, 
and  government  studies.  Subscribe  to  relevant  clipping  services, 
databases,  and  industry  analysis  groups. 

•  Develop  technology  awareness  mechanisms  (technical  libraries, 
network  services,  outside  database/library  services,  domain  experts, 
and  technology  receptor  organizations)  that  help  staff  identify  new 
technologies. 

•  Use  traditional  and  nontraditional  and  local  and  global  sources  for 
technology.  Tiraditional  sources  of  technology  include  internal  R&D 
laboratories,  universities,  computer  manufacturers,  software  vendors, 
consulting  firms,  colleagues,  literature,  seminars,  and  meetings.  Less 
traditional,  but  sometimes  even  more  effective,  sources  include  joint 
ventures,  consortium  membership,  government  laboratories,  federally 
funded  R&D  centers,  competitors,  other  suppliers,  and  customers. 

•  Participate  in  or  track  appropriate  standards  projects. 

Provide  education  and  training  in  technology. 

•  Train  and  educate  your  management  and  staff  in  new  technology-related 
skills  and  knowledge.  Most  computing-related  skills  and  knowledge 
have  a  half-life  of  about  5  years  or  less;  this  requires  the  continual 
training  and  education  of  personnel. 


External  Relationships  and  Partnerships 

For  your  organization  to  be  a  permanent  leader  in  technology  transfer,  it 
will  need  to  develop  stable  and  long-term  relationships  with  other  impor¬ 
tant  external  organizations,  including  your  customers,  suppliers  (e.g., 
vendors,  consultants),  and  industrial  peers. 

Ensure  strong  and  improving  relationships  with  external  organizations. 

•  Encourage  staff,  end  user,  supplier,  and  customer  involvement  in 
decisions  that  affect  them. 

•  Attempt  the  codesign  of  the  transfer  process  with  your  suppliers  and 
customers. 
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•  Form  ongoing  relationships  with  select  technology  sources.  This  can 
take  forms  such  as  industrial  liaison  relationships  with  universities, 
contracts,  joint  ventures,  strategic  alliances,  investment,  or  cross  own* 
ership.  Ongoing  relationships  will  help  facilitate  transfer,  give  you  in* 
fluence  on  how  the  technology  will  fit  into  your  environment,  and 
promote  support  for  the  transfer  from  the  technology  source. 

•  provide  a  vehicle  for  systematically  asking  customers  and  suppliers 
about  their  immediate  and  expected  future  technology  needs. 

8.2  JUSTIFYING  A  DEFINED  TECHNOLOGY  TRANSFER  PROCESS 

Technology  transfer  economics  is  in  its  infancy.  Though  management 
understands  the  need  to  be  successful  at  technology  transfer,  a  detailed 
understanding  of  the  costs  versus  the  benefits  of  following  a  defined  tech* 
nology  transfer  process  does  not  yet  exist.  This  section  provides  a  qualita* 
tive  cost  justification  for  the  guidebook's  use  and  then  provides  some 
empirical  data  on  technology  transfer-related  activities  in  limited,  related 
areas, 

A  qualitative  cost  justification  for  applying  the  process  in  this  guidebook 
uses  two  techniques  described  by  Barton  (1990): 

•  Value  Added  Technique.  This  technique  weighs  the  benefit  of  potential 
gains  against  expense. 

•  Strategic  Objective  Technique.  This  technique  focuses  on  the  benefits  of 
improving  a  competitive  situation  or  strategic  position  by  using  new 
technologies. 

Table  8*1  describes  these  benefits.  Many  of  these  benefits,  adapted  from 
Barton  (1990)  and  Pressman  (1992),  depend  on  the  concept  that  improving 
your  overall  technology  transfer  process  decreases  the  amount  of  time  it 
takes  to  transfer  technology. 

Thble  8-1.  Justification  for  Improving  Your  Tbchnology  Tlansfer  Process 


Benefit  Description 

Benefit 

Category 

Value  Added 

Strategic  Objective  Achieved 

Increased 
Chance  of 
Success 

You  will  increase  your 
chances  of  getting  positive 
returns  on  your  technology 
investments. 

You  will  increase  your  chance 
of  improving  your 
competitive  situation  through 
use  of  new  technologies. 

Earlier 

Accrual  of 

More  Benefits 

Your  transfer  time  will  be 
reduced  as  you  improve  your 
transfer  process. 

You  will  have  an  earlier 
time-to-market  for  products 
based  on  the  technology. 

More  of  your  staff  will 
receive  benefits  from  using 
the  technology. 
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Category 

Value  Added 

Strategic  Objective  Achieved 

Better 
Response  to 
Changing 
Technologies 

You  increase  your  ability  to 
re^nd  more  quickly  and 
effectively  to  a  changing 
technology  base. 

You  increase  the  likelihood 
that  you  will  be  using  more 
current  teduiolqgy  than  your 
competitors,  and  you  will  be 
using  what  your  customer  has 
asked  for. 

Better 

Decision 

Making 

You  will  have  faster  access  to 
more  complete  information. 

You  will  improve  your  ability 
to  predict  and  measure 
future  transfers. 

You  can  make  mme  informed 
decisions  on  the  technology 
and  the  transfer  process. 

Higher  Morale 
Among  Staff 

You  will  have  better  morale 
from  using  current 
technology  and  improved 
management  control  of  the 
transfer  process. 

You  will  increase  your 
likelihood  of  having  a  lower 
attrition  rate  when  you  have 
a  higher  morale  .among  staff. 

Better 

Technology 

Selection 

You  will  be  able  to  select  the 
technology  that  best  meets 
your  organization’s  needs. 

You  will  have  eariier 
awareness  of  new,  available 
technologies. 

Quantitative  data  for  justifying  a  defined  technology  transfer  process  can 
be  found  in  limited,  related  areas.  The  following  list  describes  two  sources 
of  quantitative  information: 

•  Surv^  of  Technology  Use.  Chris  Pickering  of  Systems  Development, 
Inc.,  surveyed  the  Fortune  500  and  the  Fortune  Service  500  in  1991  and 
provided  a  statistical  snapshot  of  their  use  of  advanced  information 
technology  (Pickering  1992).  Specifically,  for  40  of  these  companies, 
Pickering  measured  the  penetration  of  12  existing  and  emerging  infor¬ 
mation  technologies.  Though  the  survey  provides  much  more  informa¬ 
tion,  Example  8-1  reports  several  survey  findings  that  help  justify  use 
of  technologies. 

Example  8-2  lists  the  top  impediments  to  technology  use  found  by 
Pickering.  Using  the  technology  transfer  process  defined  in  this  guide¬ 
book  will  help  alleviate  the  top  two  impediments,  difficulty  to  cost  jus¬ 
tify  and  organizational/political  factors. 

•  Training.  Studies  assessing  the  training’s  impact  on  subsequent 
technology  use  reaffirm  the  key  role  training  plays  in  technology  trans¬ 
fer.  Example  8-3  recounts,  in  one  case  study,  the  importance  of 
training. 


Pidunng’s  1991  nuvey  of  technology  use  amoqg  40  Fortune  SOO  and  Fortune  Senrioe 
500  firms  includes  the  following  findings  (Pidcering  1992); 


•  Projects  that  do  use  technology  repeat  more  successes  than  foihues  Op-  I'T)- 

•  The  primary  cause  of  low,  effective  penetration  within  companies  is  simidy 
not  using  the  technologies  (p.  23) 

•  An  tedinologies  were  being  used  by  a  nontrivial  percentage  of  the 
companies.  The  technology  with  the  lovmt  penetration  was  olqect<<xiented 
methods  and  technologies  at  15%,  and  the  highest  penetration  was  end-user 
computing  at  87.5%  (p.  15-16) 

In  terms  of  the  demographics  of  the  companies  who  leqtonded:  75%  of  the 
respondents  characteriae  their  rate  of  change  as  moderate,  conservative,  or 
extremely  conservative;  over  half  of  the  companies  had  an  advanced  technology 
group;  and,  only  25%  of  the  respondents  had  a  software  metrics  program  (p.  55) 


Example  8-1.  Technology  Use  Survey  Findings 


Pickering’s  survey  of  technology  use  among  40  Fortune  500  and  Fortune  Service  500 
firms  identified  the  major  impediments  to  technology  use  (Pidcering  1992)  as  iixlieated 
in  the  chart  below  (p.  72) 


Difficult  to  cost  justify 
Organizational/politicai  factors 
No  identified  business  need 
Other* 


Percent  of  Respondents 

*  Other  reasons  given  include  lack  of  understanding  of  the  new  technology 
and  budgetary  constraints. 


Example  8-2.  Top  Impediments  to  Technology  Use 


In  a  June  1992  IEEE  Spectrum  artide.  Capers  Jones  (1992)  recewnted  a  CASEWorld 
conference  presentation  by  Chuck  House,  a  former  executive  of  Hewlett-Padcard 
Company  House  identified  training  as  the  most  notable  factor  leading  to  successful 
versus  unsuccessful  usage  of  CASE.  Specifically,  House  fmind  that  without  a 
significant  investment  in  training,  the  failure  rate  of  CASE  deployment  tends  to 
exceed  50%. 

Jones  further  states  that  House’s  observations  have  been  replicated  by  other 
organizations,  induding  Software  Productivity  Research  Incorporated.  Their 
research  has  found  that  CASE  usage  may  require  between  S0.S0  and  $100  in  training 
expenses  for  every  $1.00  spent  on  the  CASE  tools  themselves,  with  the  more 
expensive  tools  requiring  more  extensive,  costly  training. 


Example  8-3.  Impact  of  Training  on  Technology  Use 


8.  Improving  Your  Technoiogy  Itanifer  Procat 


83  WHAT  YOUR  ORGANIZATION’S  FUTURE  SHOULD  BE 

Assuming  that  all  or  most  of  the  preceding  suggested  changes  have  been 
made,  you  will  work  in  a  new  type  of  organization.  Your  organization  will 
change  proactively  at  a  rate  that  will  be  uncomfortable  but  not  debilitating. 
No  technology  will  be  totally  sacred  or  unchangeable.  The  rate  of  change 
will  be  fast  enough  to  respond  to  and  even  shape  the  external 
considerations  that  necessitate  change. 

The  resulting  situation  was  sununed  up  well  by  Steele: 

No,  the  technologically  effective  enterprise  won't  be  comfortable.  But  it 
will  prize  its  alertness,  its  adaptability,  and  its  realism  in  evaluating  itself 
and  its  environment.  It  will  be  confUent  of  its  ability  to  succeed  and  to 
survive.  Its  technologists  will  feel  secure  in  the  knowl^ge  that  technology 
plays  its  needed  role  in  all  aspects  of  the  business,  even  as  th^  compete 
with  others  for  resources  and  for  the  emphasis  they  believe  technology 
warrants.  Meanwhile,  they  will  never  lose  sight  of  the  necessity  to  achieve 
integration  between  technology  and  the  other  elements  of  a  business  and 
will  accept  both  the  strengths  and  the  constraints  that  integration 
produces  (Steele  1989, 347). 

The  world  that  you  and  your  organization  live  in  is  an  accelerating, 
increasingly  exciting,  and  potentially  hazardous  one.  Moreover,  in  your 
well  organized  enterprise,  the  interest  and  excitement  of  all  concerned 
(manager,  technologist,  and  user)  in  successfully  advancing  the  technology 
used  in  your  organization  will  exceed  any  discomfort  involved. 
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APPENDIX:  CHECKLISTS  FOR  APPLYING  THE 
TECHNOLOGY  TRANSFER  PROCESS 


Af^tndix  ObJeOive 

Provide  checklists  to 
pddeyou  through  the 
aj^ication  of  the 
technology  tranter 
process 


The  guidance  provided  in  Sections  3  through  7  presents  the  technology 
transfer  process  from  a  step/activity/task  perspective.  That  is,  the  guid¬ 
ance  is  ordered  by  step,  activity,  and  task,  with  the  guidance  tailored  for 
each  cycle  (1, 2,  and  N)  within  the  tasks. 

This  appendix  provides  a  different  view  into  the  technology  transfer 
process.  Instead  of  ordering  by  task,  the  ordering  is  done  by  cycle.  Specifi¬ 
cally,  for  each  cyclt  (1, 2,  and  N),  this  appendix  provides  a  checklist  that 
outlines  the  specific  tasks  you  would  perform  in  that  cycle.  These  check¬ 
lists  are  based  on  the  cyclic  strategies  for  technology  transfer  described 
in  Section  2.5,  under  Assumption:  Placing  Yourself  in  the  Process. 

Each  checklist  contains  a  Gimments  column.  You  can  use  this  column  to 
make  notes  to  clarify  why  a  task  was  not  checked  off  and/or  indicate  the 
person  who  checked  off  the  task. 

Tkble  App-1  provides  the  checklist  for  Cycle  1.  Tkble  App-2  provides  the 
checklist  for  Cycle  2.  Tkble  App-3  provides  the  checklist  for  Cycle  N. 


App-l 


Appeadig  ChecfclisH  for  Applying  the  TtchnotogyTtMsfefProcMi 


Ikble  App-l.  Qde  1  Iksk  Checklist 


Cycle  1  Tasks 


1.  Step  1:  Understand  Context 

Activity:  Build/Reinfoice  Sponsorshq)  and  Foundation 

□  Identity  transfer  support  staff  (change  agents  and  duunpions) 

□  Identity  end  users  and  initially  assess  their  readiness  to  change 

□  Identity  sponsors 

□  Prepare  and  implement  influence  strategy 

Activity:  DefineAJpdate  Ihinsfer  Strategies  ^ 

□  Examine  external  environment 

□  Examine  internal  environment 

□  Understand  reason  and  expected  benefits  for  the  transfer 

□  Define  objectives 

□  Identity  alternative  strategies 

□  Identity  alternative  technologies 

□  Identity  constraints 
Activity:  Understand  Process 

D  Understand  hardware  and  software  environment 
D  Understand  the  current  process 
Activity:  Context  Review 

□  Obtain  agreement  from  change  agents,  champions,  and  end 
users 

2.  Step  2:  Analyze  Risks  and  Select  Strategy 
Activity.  Analyze  and  Resolve  Risks 

□  Identity  and  analyze  risks 
D  Review  risk  analysis 

G  Evaluate  and  plan  risk  aversion 
D  Commit  to  risk  aversion  plan 

□  Execute  risk  aversion 
Activity:  Select  Strategy 

G  Selea  a  transfer  and  cycle  strategy 
G  Select  the  technology 


App-2 


Cycle  1  Tasks 


Activity:  Commit  to  Strategy 

□  Obtain  review  and  approval  from  champions  and  change  agents 

3.  Step  3:  Plan  Ibchnology  Implementation 

You  will  perform  no  activities  or  tasks  in  this  step  in  Ctycle  1. 

4.  Step  4:  Implement  Ibchnology 

You  will  perform  no  activities  or  tasks  in  this  step  in  Cycle  1. 

5.  Step  5:  Review  and  Update  Ihuisfer  Plan 
Activity:  Review  Progress 

□  Collect  data  on  technology  transfer  process 
Activity:  Define  Thmsfer  Plan 

□  Define  recommendations  and  transfer  plan 
Activity:  Commit  to  Proceed 

n  Obtain  commitment  from  change  agents,  champions,  and  end 


Ctminieiits 
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'I^leApp-2.  C^cle  2  Ihsk  Checklist 


Cycle  2  Tssks 


1.  Step  1:  Understand  Context 

Activity:  Build/Reinforce  Sponsorship  and  Foundation 

□  Build  transfer  support  staff  (change  agents  and  champions) 

□  Assess  end  user  readiness  to  change 

□  Build  ^nsorship 

□  Update  and  Implement  influence  strategy 
ActiviQr:  Define/Update  Thmsfer  Strategies 

□  Examine  external  environment  (if  needed) 

□  Examine  internal  environment  (if  needed) 

□  Understand  reasons  and  expected  benefits  for  the  transfer 
(if  needed) 

□  Define  objectives 

□  Identify  alternative  strategies 

□  Identify  alternative  technologies  (if  needed) 

□  Identify  constraints 
Activity;  Understand  Process 

□  Understand  hardware  and  software  environment 

□  Understand  the  current  process 
Activity;  Context  Review 

□  Obtain  agreement  from  change  agents,  champions,  and  end 
users 

□  Obtain  commitment  from  sponsors 

□  Publicize  commitment 

2.  Step  2:  Analyze  Risks  and  Select  Strategy 
Activify:  Analyze  and  Resolve  Risks 

□  Identify  and  analyze  risks 

□  Review  risk  analysis 

□  Evaluate  and  plan  risk  aversion 

□  Commit  to  risk  aversion  plan 

□  Execute  risk  aversion 


Comments 
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‘Qble  Ap^2,  continued 


Cycle  2  Tksks 


Activi^.  Select  Strategy 

□  Select  a  transfer  and/or  cycle  strategy 

□  Select  the  technology  (if  needed) 

Activity:  Commit  to  Strategy 

□  Obtain  review  and  approval  from  champions,  change  agents, 
and  end  users 

□  Obtain  commitment  from  sponsors 

□  Publicize  commitment 

3.  Step  3:  Plan  Ibchnology  Implementation  ^ 

You  will  perform  no  activities  or  tasks  in  this  step  in  Cycle  2. 

4.  Step  4:  Implement  Ibchnology 

You  will  perform  no  activities  or  tasks  in  this  step  in  Cycle  2. 

5.  Step  5:  Review  and  Update  Ihmsfer  Plan 
Activity:  Review  Progress 

□  Collect  data  on  technology  transfer  process 
Activity.  Define/Update  Thinsfer  Plan 

□  Define  recommendations  and  update  transfer  plan 
Activity  Commit  to  Proceed 

□  Obtain  commitment  from  change  agents,  champions,  and  end 


Commeots 


n  Obtain  commitment  from  sponsors 
□  Publicize  commitment 
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Thblc  App-3.  Cycle  N  Tiisk  Checklist 


Cycle  N  Tasks 


1.  Step  1:  Understand  Context 

Activity:  Build/Reinforce  Sponsorship  and  Foundation 

□  Reinforce  transfer  support  staff  (change  agents,  champions) 

□  Assess  end  user  readiness  to  change 
O  Reinforce  sponsorship 

□  Update  and  implement  influence  strategy 
Activity:  Define/Update  Transfer  Strategies 

□  Examine  external  environment  (if  needed) 

□  Examine  internal  environment  (if  needed) 

□  Understand  reasons  and  expected  beneHts  for  the  transfer 
(if  needed) 

□  Define  objectives 

□  Identify  alternative  strategies 

□  Identify  alternative  technologies  (if  needed) 

□  Identify  constraints 
Activity:  Understand  Process 

□  Understand  hardware  and  software  environment  (if  needed) 
D  Understand  the  current  process  (if  needed) 

Activity:  Context  Review 

□  Obtain  agreement  from  change  agents,  champions,  and  end 
users 

G  Obtain  commitment  from  sponsors 

□  Publicize  commitment 

2.  Step  2:  Analyze  Risks  and  Select  Strategy 
Activity:  Analyze  and  Resolve  Risks 
G  Identify  and  analyze  risks 
G  Review  risk  analysis 
G  Evaluate  and  plan  risk  aversion 
G  Commit  to  risk  aversion  plan 
G  Execute  risk  aversion 


Comments 
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'Elble  ^p-3,  continued 


Cycle  N  'Risks 


Activity:  Select  Strategy 

□  Select  a  transfer  and/or  cycle  strategy 

□  Select  the  technology  (if  needed) 

Activity:  Conunit  to  Strategy 

□  Obtain  review  and  approval  from  champions,  change  agents, 
and  end  users 

□  Obtain  commitment  from  sponsors 

□  Publicize  commitment 

3.  Step  3:  Plan  Tfechnology  Implementation 
Activity:  Define  Implementation  Plan 

□  Define  success  criteria  and  associated  data  collection 
requirements 

□  Define  implementation  tasks 

□  Define  budget  and  staffing 

□  Identify  and  analyze  risks  associated  with  implementation  plan 
Activity:  Commit  to  Implementation  Plan 

□  Obtain  review  and  approval  from  change  agents,  champions, 
and  end  users 

□  Obtain  commitment  from  sponsors 

□  Publicize  commitment 

4.  Step  4:  Implement  Tfechnology 
Activity:  Implement 

□  Carry  out  implementation  plan 

□  Reinforce  sponsorship 

□  Address  resistance  to  change 

□  Support  the  users 
Activity:  Manage  and  Monitor 

□  Manage  implementation 

□  Gather  implementation  data 

□  Determine  progress  of  implementation  against  the  plan 

□  Identify  and  analyze  risks  associated  with  implementation 


Comments 
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Ihble  App-3,  continued 


Cycle  N  Tasks 


Activi^.  Review  Tbchnology  Implementation 

□  Collect  and  review  process  assets 

□  Collect  and  review  cycle-level  lessons  learned 
5.  Step  S:  Review  and  Update  Tlansfer  Plan 

Activity.  Review  Progress 

□  Compare  implementation  data  to  objectives 

□  Collect  data  on  technology  transfer  process 

□  Collect  and  review  transfer-level  lessons  learned 

□  Baseline  process  assets  and  lessons  learned 
Activity:  Define/Update  Hansfer  Plan 

□  DeHne  recommendations  and  update  transfer  plan 
Activity:  Commit  to  Proceed 

□  Obtain  commitment  from  change  agents,  champions,  and  end 
users 

□  Obtain  commitment  from  sponsors 
n  Publicize  commitment 


Comments 
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LIST  OF  ABBREVIATIONS  AND  ACRONYMS 


ADARTS 

CASE 

CEM 

CMM 

DoD 

ESP 

GQM 

ISO 

R&D 

SEI 

SEPG 


Ada-based  Design  for  Real-Time  Systems 
computer-aided  software  engineering 
Comparative  Evaluation  Method 
Capability  Maturity  Model 
Department  of  Defense 
Evolutionary  Spiral  Process 
Goal-Question-Metic 
International  Standards  Organization 
research  and  development 
Software  Engineering  Institute 
Software  Engineering  Process  Group 
Total  Quality  Management 


TQM 


List  of  Abbrevi«tk>oi  »nd  Acronyms 


This  page  intentionally  l^  blank. 
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GLOSSARY 


Activity 

Adaptability 

Authorizing  sponsor 

Awareness 

Capability  Maturity  Model  (CMM) 

Champion 

Change  agent 
Compatibility 

Complexity 

Constraint 

Consumer 


A  step  of  a  process,  the  performance  of  which 
satisfies  objective(s)  supporting  that  process.  An 
activity  includes  other  steps. 

The  degree  to  which  a  technology  can  be  adapted  to 
suit  the  specific  environment  and  needs  of  the 
organization  using  it. 

A  person  who  possesses  sufficient  authority  or 
influence  to  initiate  resource  commitment  for  the 
transfer.  See  also  Sponsor  and  Reinforcing  sponsor. 

The  activities  performed  by  a  person(s)  or 
organization(s)  to  acknowledge  and  become  aware  of 
a  technology. 

A  software  development  maturity  model,  developed 
by  the  Software  Engineering  Institute,  that  provides 
a  framework  to  assist  organizations  in  improving 
their  software  process  (Paulk  et  al.  1991). 

A  person  who  advocates  and  publicly  supports  use 
of  a  new  technology  in  an  organization,  but  lacks 
power  to  provide  resources  to  support  it. 

A  person  or  team  empowered  by  the  sponsor  that 
pexforms  the  technology  transfer  activities. 

The  degree  to  which  a  technology  is  perceived  as 
consistent  with  the  ensting  values,  past  experiences, 
and  needs  of  potential  users  (Rogers  1983). 

The  degree  to  which  a  technology  is  perceived  as 
relatively  difficult  to  understand  and  use  (Rogers 
1983). 

A  limitation  on  decision(s). 

A  person  or  group  responsible  for  becoming  aware 
of,  evaluating,  deciding  on,  planning,  and  using  a  new 
technology. 


Gio-l 


Gloa««iy 


Customer 

cycle 

cycle  risk 

Decision 
End  user 

Engineer 

Environment 

Evaluation 

Evolutionary  Spiral  Process 
(ESP) 

Goal 

Grass>roots  campaign 
Implementation 

Influence  campaign 


The  person(s)  or  organization(s)  that  specifies  the 
requirements,  accept,  and  authorize  payment  for  a 
product. 

A  (^cle  is  a  complete  traversal  of  the  five  steps  of  the 
Evolutionary  Spiral  Process. 

A  risk  of  the  current  cycle,  usually  at  the 
implementation  or  tactical  level. 

A  choice  among  allowable  alternatives. 

The  person(s)  or  organization(s)  that  will  use  the 
technology  for  its  intended  purpose  when  it  is 
deployed  in  its  environment.  See  also  User. 

A  person  who  performs  technical  activities  for  a 
project. 

All  external  and  internal  conditions  that  influence 
the  form,  performance,  reliability,  or  survival  of  an 
organization. 

The  activities  performed  by  a  person(s)  or 
organization(s)  to  understand  how  a  technology 
works,  what  is  its  purpose,  and  whether  it  is  suitable 
for  use  within  the  organization. 

Any  enactment  of  the  evolutionary  spiral  model 
which  is  an  adaptation  of  the  basic  spiral  model  pro> 
posed  by  Barry  Boehm  (1986;  1988)  that  emphasizes 
the  evolutionary  development  of  systems. 

A  specific,  time-related,  measurable  target. 

The  activities  taken  by  an  organization’s  staff  to  gain 
buy-in  from  management  on  a  technology  transfer. 

Die  activities  performed  by  a  person(s)  or 
organization(s)  to  acquire  and  incorporate  a  technol¬ 
ogy  into  existing  organizational  work  enviroiunents. 

The  activities  taken  to  gain  buy-in  from  appropriate 
management  and  staff  on  the  technology  and  its  use 
within  the  organization.  See  also  Influence  strategy. 
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Influence  strategy 


Infrastructure 

Institutionalization 

Manager 

Measurement 

Method 

Metric 

Objective 

Observability 

Process 

Process  Action  Team 


A  formal  or  infonxud,  written  or  unwritten  strategy 
for  gaining  bi^-in  from  apprr^riate  management 
and  staff  on  the  technology  and  its  use  within  the 
organization.  See  also  Influence  campaign. 

The  staff  and  organizatirmal  support  required  to 
make  the  transfer  succeed. 

The  activities  performed  by  a  person(s)  or 
organization(s)  by  an  organization  to  make  a  technol* 
ogy  a  routine  and  necessary  part  of  the  organization’s 
work  environment 

A  person  responsible  for  the  management  of  a 
project  and/or  for  the  definition,  cost  and  schedule 
of  a  product 

A  number  assigned  to  a  directly  observable  aspect  of 
a  process  or  product 

Guidance  and  criteria  that  prescribe  a  systematic, 
repeatable  technique  for  performing  an  activity. 

A  function  of  one  or  more  measurements.  A  metric 
may  be  directly  observable  or  may  be  derived 
through  a  calculation  involving  one  or  more  metrics 
and  measurements. 

The  intended  or  desired  result  of  a  course  of  action. 

The  degree  to  which  the  results  of  technology  use  are 
visible  to  others  (Rogers  1983). 

A  (partially)  ordered  set  of  steps,  intended  to 
accomplish  specified  objective(s). 

A  group  that  is  responsible  for  developing  and 
implementing  a  plan  to  improve  a  specific  area  of  the 
process. 

Documentation  or  work  products  (e.g.,  reports, 
memos,  policies,  and  procedures)  developed  during 
the  technology  transfer  process  that  support  the 
transfer. 


Process  assets 


Gloisaiy 


Process  Group 

Producer 

Readiness  to  change 
Reinforcing  sponsor 

Relative  advantage 

Resources 

Risk 

Risk  analysis 
Risk  aversion 
Risk  management 

Role 

Spiral 

Sponsor 


A  group,  as  defined  by  the  SEI,  that  is  resptmsible 
for  maintaining  and  improving  the  process  stan* 
dards,  policies,  and  procedures,  as  well  as  raining 
any  process  models  and  historical  data.  For  software 
engineering  organizatitms,  this  group  is  often  called 
the  Software  Engineering  Process  Group  (SEPG). 

A  person  or  organization  who  provides  technologies 
and/or  support  services  to  consumer  organizations. 

An  organization’s  receptiveness  to  and  ability  to 
chan^. 

A  person  who  possesses  sufficient  authoriQr  or 
influence  to  reinforce  the  transfer  efforts  at  the  local 
level.  See  also  Authorizing  sponsor  and  Sponsor. 

The  degree  to  which  a  technology  is  perceived  as 
being  better  than  the  technology  that  it  supersedes 
(Rogers  1983). 

People,  time,  and  money. 

A  potential  for  incurring  undesirable  results. 

The  act  of  identifying,  estimating,  and  evaluating  risk 
to  determine  whether  risk  aversion  is  necessary. 

The  act  of  reducing  a  risk  to  an  acceptable  level  by 
changing  the  probability  or  cost  of  a  risk  occurring. 

A  management  approach  focused  on  identifying, 
addressing,  and  removing  risk  items  before  they  be¬ 
come  either  threats  to  successful  product  operation 
or  major  sources  of  rework. 

A  function  within  the  technology  transfer  process. 

One  or  more  cycles  of  the  Evolutionary  Spiral 
Process  that,  when  combined,  accomplish  a  specific 
objective. 

A  person  who  possesses  sufficient  authorify  or 
influence  to  either  initiate  resource  commitment  for 
the  transfer  or  reinforce  the  transfer  efforts  at  the  lo¬ 
cal  level.  See  also  Authorizing  sponsor  and 
Reinforcing  sponsor. 
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Sponsorship 


i 

I 


Stakeholders 

Start  criteria 
Steering  Committee 


Step 

Stop  criteria 

Suppliers 

Iksk 

Tfechnology 

Technology  transfer 


Transfer  risk 

Trialability 

User 


Management  support,  including  the  provision  of 
resources  to  support  the  transfer  and  coinmunica> 
tion  of  support  to  the  rest  of  the  organizatitm. 

All  persons  or  groups  who  are  involved  with  or 
affected  by  the  techndt^  transfer. 

Conditions  that  must  be  met  before  an  activi^r  can 
be  started. 

The  organization  that  sets  priorities  for  process 
improvement  initiatives  and  recommends  to  the 
sponsor  the  authorization  of  all  actions  undertaken 
by  the  Process  Group. 

Either  an  activiQr  or  an  unelaborated  action. 

Conditions  that  must  be  met  before  an  activity  is 
considered  complete. 

A  producer  who  provides  technologies  and/or 
support  services  to  your  organization. 

A  work  assignment  (i.e.,  subject  to  management 
accountability)  to  accomplish  a  specified  objective. 

Techniques,  tools,  or  knowledge  that  aids  in 
accomplishing  some  task  (adapted  from  Williams 
and  Gibson  [1990]  and  Software  Productivity 
Consortium  [1988]). 

Hie  process  by  which  a  technology  goes  from 
development  by  a  technology  producer  to  use  by  a 
technology  consumer.  This  term  is  sometimes  re¬ 
ferred  to  as  technology  transition  or  technology 
insertion. 

A  risk  of  the  entire  transfer.  Usually  at  the  strategic 
level. 

The  degree  to  which  a  technology  can  be  used  on  a 
h'mited  basis  (Rogers  1983). 

The  person(s)  or  organization(s)  that  wll  use  the 
technology  for  its  intended  purpose  when  it  is 
depleted  in  its  environment.  See  also  End  user. 


Vendor 


A  supplier  of  commercial  off-the-shelf  tools  or 
software. 
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Understand  Process,  3-20, 3-27, 3-31 
Analyze  and  Resolve  Risks  activity,  3-5, 3-6, 3-22, 
3-28, 3-29, 4-2, 4-15,  5-9,  6-11, 7-10, 7-11 
activity  djjective,  4-2 


Build/Reinforce  Sponsorship  and  Foundation 
activity,  3-2, 3-22, 3-29, 3-31,  3-32,  4-19, 5-12, 
7-16,  7-17 

activity  objective,  3-2 


Capability  Maturior  Model,  1-3, 1-4 
Champion,  3-2, 3-3 
definition  of,  2-11 

obtain  agreement  from,  3-31, 4-17,  5-11, 7-16 
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activity  objective,  4-13 
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reinforcing  sponsor,  2-11, 3-6, 3-8 
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Support,  5-7, 6-3, 6-5,  8-5 

for  initial  implementation,  5-8 

for  new  users,  5-8 

hot-line  support,  5-8 

producer  vs.  internally  supplied,  5-8 


Ibchnical  support.  See  Support 
Ibchnology 

adaptability,  2-8, 5-5 
approve  selection  of,  4-17 
assessing  impact,  7-5 
characteristics,  5-5 
compatibility,  2-8,  5-5 
complexity,  5-5 
consistency  with  culture,  1-1 
consistency  with  needs,  1-1 
deviation  from  current  practices,  3-29 
identifying,  3-20 
integration  issues,  3-28 
maturify,  2-8 
observability,  2-8 
rate  of  change,  1-2 
relative  advantage,  2-8 
requirements,  3-20 
benchmarking,  3-21 
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cycle  2  strategy,  2-12 
cycle  duration,  2-9 
cycle  N  strategy,  2-12 
cycle  objectives,  3-18, 7-6 
cycle  planning,  2-9 
cycle  strategies,  2-12 
cycle-level  lessons  learned,  7-8, 7-9 
example  scenario,  2-2 
cycle  1,  2-3 
cycle  2,  2-4 
cycle  N,  2-5 

expected  benefits  of  transfer,  3-18 
e}q>lanation  of  structure,  2-1 
guidance  for  using,  2-11 
improving,  8-1 

frequency  of  transfers,  8-1 
organizational  relationships,  8-1 
influences 

end  user  characteristics,  5-5 
technology  characteristics,  S-S 
justification  for,  8-7 

qualitative  cost  justification,  8-7 
survey  of  technology  use,  8-8 


Incl-4 


